Almost 3 years ago, I earned my AWS Solutions Architect Associate certification. This past week, I took the exam again and passed in order to renew that certification for another 3 years. I drive about 90 minutes to my preferred Pearson VUE exam location, but this time I had to make the 90 minute drive back without knowing my exam outcome. Amazon now reviews things afterwords. I received no email yet, but within 24 hours my Exam History section on their certification portal was updated with my outcome. AWS has given me scores immediately on my last three exams; the technology exists, so give me a score right away and review things later to make it official if you need to. Anyway!

I did not study as much as I wanted or should have this year. I hadn’t intended to take the exam in October, but at the start of the month when I looked for times to book, my preferred venue had all sorts of times in October, and none at all in November or December. So, I snap booked as far out as I could, and got to work studying. Unfortunately as timing would go, Wild West Hackin’ Fest occurred which I not only attended virtually, but took some intense training in the first few days as well. I’ll come back to this later as notes to my future self 3 years from now.

Last go around, I used A Cloud Guru courses, Linux Academy courses (namely Adrian Cantrill’s excellent course), and practice exams from Jon Bonso (Tutorials Dojo). Since then, the landscape has changed as both Linux Academy and A Cloud Guru have been swallowed up by other players, and more honesty has been openly shared about the latter’s quality of offerings. (I really wasn’t terribly impressed 3 years ago, but ACG seemed to be everyone’s darling at the time.) This year I also have access to many Udemy offerings for free through my employer.

I started out purchasing and going through Jon Bonso’s Tutorials Dojo SAA-C03 course on his own platform. I loved his practice tests 3 years ago, so I figured I’d also do his course. In retrospect, this course wasn’t right for me, nor did I enjoy the platform. The platform doesn’t give me a good idea how long the whole course or sections are, and the player never saved the speed settings I preferred (1.25x-1.5x speed). The course itself was also…for lack of a better way to put it…not filling enough of my knowledge taste. Lots of slides. There is something to be said about even watching someone else use the AWS console to do things, which helps show the features and settings in more context. There was very little of that in this course.

Next, I started doing the set of SAA-C03 2022 Practice Exams on Tutorials Dojo. These are still absolutely excellent. Previously there were 6 exams, but now there seem to be 6 timed ones, 6 that show the answer as you go, and several other topical sets. There are times where it feels some questions reappear from one test to another, but I still feel these are the best practice questions that reflect both the subjects and the feel/style of the official AWS questions. Highly recommend.

Lastly, I went through most of the Udemy course, Ultimate AWS Certified Solutions Architect Associate SAA-C03, by Stephane Maarek. This is a phenomenal course that I absolutely loved. I have nothing bad to say about it at all. I love that Stephane goes through the materials, but then also goes through many of the services and concepts hands-on in the console where we get to see him build things and tear things down such that we could do these in our own AWS Accounts if we want to. I made it about 50% through this course and focused on my weaker areas.

And that was all the time I found I had to study, which left me rather worried and feeling less prepared than I prefer to feel for exams like this.

For future me, here’s my suggestions. First, schedule early even months out. This provides the most flexibility to study appropriately while also allowing plenty of time to do all the practice tests and really get used to the topics over time. Normally, I am very good about this and my planning, but this year has been hectic. Second, look up these authors (in any order) and take their courses: Adrian Cantrill, Stephane Maarek, Neal Davis, Jon Bonso (practice exams). Maarek and Davis also have practice exam sets, but I did not get a chance to sample them. Third, look at the AWS exam guidelines and scope document, but do not get distracted by new and specialized services. Keep focus on the core important services. You’re far more likely to get 5+ questions on Lambda than on AWS Polly. For the latter, know their elevator pitch, purpose, and if there are sub-services to know. Fourth, do practice exams every few days if possible. Don’t go through any a second time, as that is just an exercise in memorization/recall of specific questions. Amongst the authors above, there are *months* of practice exams to consume for relatively little cost. Do them, and the real exam will feel like a familiar place.

I think I said it before, but I’ll say it again this year: I feel that every single question on the exam is directly sourced from either the AWS official documentation or from the AWS blogs/whitepapers which cover using services, service features, or designing for certain use-cases/situations. And while that may seem obvious, it bears repeating to let that sink in: read the things. Also, any hands-on whether it’s watching someone else or doing it yourself in a lab or for your own personal or work stuff is necessary in order to see features and settings in context and in action. I mean, this certification is meant for people with 1+ years experience in the role!

Next up is renewing my AWS Security Specialty certification, and then in 3 years deciding what to renew or advance.

I’ve done many labs and CTFs and lots of studying and taken so many notes (…so many notes…), but one thing I don’t think I’ve ever done is compose and publish a write-up on something. When BTLO retired a few lab investigations a few weeks ago, I thought maybe I’d spend some time to create a template and reorganize my notes into a public write-up I can share. And I did two of them!

First, I created a write–up for the PhishyV2 investigation which involved analyzing a phishing site and kit. This was a lab that was rated Hard on the BTLO site, and one of the earlier labs I completed after joining the site.

A week later, I made another write–up for the Obfuscated investigation. This one is geared around responding to an incident where an internal employee was given some malicious Python code which they executed and led to a compromise of their Linux workstation. The investigation is really broken down into two main parts. First, analyzing and deobfuscating a python script. And second investigating the Linux environment for signs of persistence.

I am no Word wizard, so this also let me brush some dust off my Word skills. I also normally do not take extensive screenshots for my personal notes, relying more often on text and terminal output. And this helps me also be more comfortable in quickly taking some screenshots to assist with my notes clarity. Often, taking screenshots has been something that gets me out of my normal flow of thought, and the only way to fix that is practice and ingraining it into my workflow.

Hopefully more labs retire in the future, and I’ll probably work on doing a few more write-ups for the harder or notable challenges.

In 2020, I started doing exercises on the PentesterLab (PTL) platform. To date, I’ve earned 16 badges (certificates) on the site, and have completed 440 exercises with only 13 currently available exercises left to tackle. Last night I became the 4th completion of the Brown Badge, and I realized I’ve never really shared or posted about my efforts or thoughts on the site.

PentesterLab is an online platform founded by Louis Nyfenegger which aims to teach students web application testing skills using hands-on curated labs that require practical skills to solve exercises. You know, for web pentesting and bug bounty hunting! The lab exercises are largely performed on a web application that the platform spins up, and students attempt to find a hidden key or achieve execution of a scoring binary on the target system to get the exercise completed. A huge section of code review challenges is an exception to this formula where students provide the file name, line number, and type of vulnerability present in order to score the exercise as completed.

All exercises include an introductory description, though some are quick and throw students right into the challenge, while others provide lengthy in depth discussions of the techniques and exploits utilized. I’ve always found these to be at the right level of detail for me to see success on the platform, with a nice mix of research, reflection, and rote practice.

Many exercises have video solutions posted by Louis, but if you play along early enough before they get posted, you don’t have the luxury of a solution key to fall back onto. Plenty of the exercises still today do not have solutions posted, adding to the challenge of completing some of the badges. But, most of them do, which allows students to challenge themselves at their own tolerance levels before peeking at the videos. Also, those videos don’t actually give you the scoring key. To score a completion, students still have to go through the practical steps to exploit and solve the exercises.

Overall, it’s been an excellent platform I’ve been on for a few years and has helped me learn a ton of things relating to web app security.

Surprisingly, the exercises have a decent replay value to them. With so many, by the time six months pass, I won’t remember all the solution details if I revisit something. But, more importantly, I can solve them in different ways. A good example is the HTTP badge, which can be entirely solved using curl commands, but I also have chosen to solve them with Python and Ruby scripts as well. Many solutions can be derived using a scripting language of choice, providing additional opportunity to hone new skills. The platform accommodates this as you can run the scoring binary again, and the site will tell you it was a fresh score. And obviously you can just retrieve the correct key from the site for those challenges.

Another thing I like about the platform is how it dances between the line of being a platform of exercises versus a platform that is just a course. It really ends up doing both, which I appreciate and fits into the way any penetration tester should be learning and tackling these things. Courses are great to teach things, but practical exercises are irreplaceable hands-on opportunities. And leaving some details out or fuzzy will cause the student to do some outside research, think a little, try and fail at things, and then try harder. And this is ultimately the mindset a tester needs to have, since they won’t normally have access to hints, nudges, or answers out in the real world of testing.

Much like almost any pentesting lab or series of challenges, there are also some very specifically vulnerable entries that are unlikely to be found in the wild, but they do act as ways to think about things differently, or open creative avenues that may be useful in the future, even if today that particular vulnerability is solved or just so derived that it’s not realistic.

My scripting skills have markedly improved in Python and Ruby during this course. Coming into this, I was passable with Python and had 0 experience with Ruby beyond maybe running an exploit of EDB or something. But, during this course I’ve had the chance to write more Python and Ruby scripts, or edit and adjust existing ones or those from the answer videos, that I feel comfortable digging into deeper topics and weaponizing exploits. In addition, students can walk away with scripts that can act as frameworks for future endeavors. Maybe a script to generate a tampered JWT will work in other engagements, or maybe that deserializer can be used the same way for a test a year from now.

Likewise, I’ve used Burp Suite for many years, but like any complex tool, that skill only sticks around as long as one greases the wheels on a regular basis and uses it. I get to drop into Burp on most exercises, and poke and prod and learn new things.

And just like any pentesting learning platform, all of this is often about three important things: exposure, experience, and practice. PTL ends up providing all three, which is great for building a body of experience and confidence in the skills.

For someone looking to prep for something like the OSCP, I’d say there’s no real hand-holding here to get your testing platform up and running or for easing into understanding and using Kali, Linux, Burp, HTTP, or other possible tools. Still, the badges I suggest below to start out will still be helpful to anyone going for their OSCP, as there is still plenty of web application exploits and targets present in the OSCP course and exam.

For someone looking to get into we app pentesting or bug bounties or even pentesting in general, I’d say do everything here! As far as skill level expected, I’d say something like the SANS SEC542 course and GWAPT exam probably can act as a more introductory-friendly way to dive into web app testing and understand the essentials, but I’d immediately follow that up with running through PTL. OSCP courses and things like eCPPT probably similarly can ease students less comfortable with things like Linux and Burp and web coding concepts.

Students who find the most success, though, should come to this platform with a comfort level in operating Kali Linux, web server architecture (most specifically Apache server operation), using Burp Suite (proxy and repeater, nothing intense), maybe a fuzzer like wfuzz, reading packet captures, and definitely have some comfort level in or ability to learn web code and scripting. Good examples will be some php, javascript, and java, but mostly python and ruby. This may sound daunting, but most of this is about exposure and being in a position to take the next steps and not be hung up on what Python is or what cat /etc/passwd means or how to intercept using Burp. I’m not sure PTL is good for “My First Reverse Shell From a Web Server,” but it’ll be the next steps after the first one.

The platform is not entirely clear what order to tackle the badges in. I’ll attempt to provide some guidance here, but generally speaking, tackle the ones that have the most completions first, and the ones with less completions later on.

I would suggest students or those with newer skill levels in the topics tackle these badges first: INTRODUCTION, ESSENTIAL, UNIX, RECON, HTTP, PCAP. These all really hone in on specific tasks and other foundational concepts that will be useful at all levels. And for those who know these topics, you may still learn something new of have an opportunity to solve them in different ways. For example, maybe parse the PCAP programmatically instead of in Wireshark. Or in the HTTP badge, script the solutions rather than use curl. The Essential badge is where you find your beginner types of web app topics.

From here, you can honestly go anywhere else, but continue on for general guidance.

The API badge could be something to tackle next. This badge isn’t totally released at the time of this writing, but the exercises are pretty basic to date and follow the ESSENTIAL badge topics pretty well.

Going down the rabbit hole of the other badges, here’s a good route to follow: WHITE, YELLOW, BLUE, SERIALIZE, GREEN, BROWN. Most of these progress naturally, though the BROWN badge sometimes feels like it has exercises that could be slotted into the other badges, but those badges were already complete when these new CVE’s or attacks came out, and just needed a place to land. Still, several BROWN exercises directly suggest solving some others scattered elsewhere first.

The INTERCEPT and ORANGE and AUTHENTICATION/AUTHORIZATION badges are more intense as far as requiring more work on the student to host things like a DNS server or a public endpoint to perform XSS or other reflection attacks. These definitely present a different set of challenges. The AUTHENTICATION/AUTHORIZATION badge is all about SAML and OAuth, but again often require you to host an endpoint that is part of the exploitation path.

The CODE REVIEW badge is a weird one in that you’re reading code and identifying the problems in that code. There are also tons of videos separate from the exercises. Some of these give a half-dozen lines making them kind of easy, while others are long sections of code across multiple files which increases the difficulty of finding the needle in the haystack, as it were. Since this badge is super long and not completed yet, I suggest tackling these in between other badges to keep things fresh. Also, I consider this badge super unique in that I’ve not really seen exercises elsewhere before that specifically target code reviewing skills.

The ANDROID and CAPTURE-THE-FLAG badges are sort of one-off badges students can do whenever. ANDROID is specific to Android applications, and I have no idea how difficult these really are. Java and Android are well outside my comfort zone, so I leaned heavily on the videos to progress through these. The CAPTURE-THE-FLAG badge contains some common CTF-like challenges that involve web or crypto-related topics. They’re fine, but definitely not common fare for web app pen testers.

To date, I have done none of the JAVA SERIALIZE or MEDIA badges, so I can’t comment on those.

Overall, my time in this platform has been good and I’ve learned a ton and gained lots of confidence when it comes to understanding and even walking through various web exploits and weaknesses. I’m no developer, but I think I can hold my own discussing security topics on a practical level like one, though.

(Pet peeve: Articles that don’t have dates on them. Don’t be that type of site. Ok, I know the article I link to is dated in 2021 [if you turn on javascript], but the note that I made to myself referencing this article was made in 2019…)

A post over on CSOOnline, “How the CISO role is evolving,” goes over some interesting discussion points about the CISO role.

I initially targeted my notes on the list of skills for the CISO:

• Security operations
• Cyberrisk and cyber intelligence
• Data loss and fraud prevention
• Security architecture
• Identity and access management
• Program management
• Investigations and forensics
• Governance

Holy cow, is there anything in Infosec left untouched there? Then again, CISO is the top of that leadership pyramid, right? But, this illustrates to me how difficult the CISO’s job will be if they do not report into or next to the IT overall organization. Reporting outside of IT means lots of consulting and ultimately audit-like tasking that hopes all of the above items end up getting done (and likely won’t be). And I’ve yet to see IT auditing being even partially effective or useful.

Later in the article, it starts to get real about the most important job requirement for a CISO role not necessarily being the technical understanding. I think it’s true that at this level, a key skill is “advocating for security within the company leadership.”

I think leadership traits are also important, but that’s always a funny thing within any department, team, or organization. Particularly in a technical field. At least for me, technical credibility is a key trait of leaders I respect and react positively towards. Someone who does not understand the technical aspects and demonstrates this by being wrong on a regular basis, just do not get respected by me and will not be a good leader for me. And it’s not like I need them to be highly technical; but I need them to be technical enough to know and be open about their limitations, and big enough to allow others to fill in the gaps. Leaders who get technical things wrong, don’t understand that they’re wrong, and thus never seek information from their team in order to make proper decisions, are what cause security to take steps backwards.

And it’s not just me, but many technical teams will stop listening to security if the people they interact with are regularly wrong, or vague, or confusing, or belligerent, or just not keeping up. Technical people who know the right answer don’t tolerate people who cling to wrong answers.

Another way to say this is the CISO needs to know enough to know their team is performing as needed, or if they need assistance.

I don’t recall where I found this graphic, but at least it has citation on it. I liked it enough to keep it, and just wanted to move it out from my personal notes into here.

I do like these steps, though obviously there are plenty ways to tackle this problem. And if someone needs or needs to show some sort of process/plan, this makes a good pragmatic start.

One thing I would change on this is to make sure this isn’t like a 1-year process right here. I feel like steps need to be taken pretty quickly to start *doing* something and getting some output and value. For example, Step 7 shouldn’t be waiting for earlier steps to develop. Step 7 should strive to start as soon as positive movement can be achieved. Early, easy wins, or foundational pieces.

I also prefer to think in terms of maturity levels based on some sort of model. I think that’s what is meant here by tiers. That is just a difference in preferred terminology.

Threat hunting is a cool term. It’s so cool that so many people, managers, and marketers have latched onto it and used it to describe almost anything you can think of from pen testing to SOC operations to red teaming to incident response. It’s become a pet peeve of mine how badly “threat hunting” is mis-used and mis-understood.

And I’m still convinced that threat hunting started for two main reasons. First, to slip in between the major efforts already in play between detection engineering (the blue team SOC), incident response which tackles found things, and handling threat intelligence, which usually ends up being an automated feed and corrrelation mechanism within a SIEM. Another way to put it: the human in between the matured automated technical activities.

And second, something for bored internal red teamers, IR folks, and senior detection engineers to do in between the main projects. (I’m joking, but I’m not….but I am…)

I just skimmed through a free PDF that caused me to make this post to keep this link around and share it: Threat Hunting Essentials, Part 1: Threat Hunting Defined, by Fidelis Cybersecurity.

In this, they not only talk about a good definition of Threat Hunting, but also examples of what it is not. This is super important, because I’ve talked to way too many people from keyboard warriors in the trenches up to management and executive levels who have the wrong idea of what Threat Hunting is. And having it wrong almost certainly means the chances of a successful threat hunting team are limited, and they probably won’t be happy hunters if everyone is operating under slightly different missions. That is bad friction.

Fidelis gives this definition:

“Threat hunting is the proactive hypothesis driven discovery of artifacts, activity, or detection methods not accounted for in passive monitoring capabilities.”

And see, even trying to isolate a good definition like this will still be open to interpretation. It is best to read the entire paper, as they do an amazing job of framing the problem, tackling the problem with easily understood examples and language, and allowing it all to funnel down into something that I consider easy to handle. There’s lots of good examples and discussions over recent years, but it’s been hard to find one so clear and yet (mostly) concise enough to present to others.

And yes, it can still be done by bored internal red teamers, senior detection engineers who need a break, or incident responders that don’t have any incidents being currently worked. But the inputs, outputs, methods, results, and expectations need to get aligned in order for the mission to add value and be successful.

And I’ll also just add that Threat Hunting is an advanced activity. It should only be a thing with maturing security operations and engineers teams, and only for those with senior skills in understanding offensive tactics, forensics artifacts left behind, and where the gaps in blue team visibility occur.

This is my sixth year openly posting about my learning and training goals, though it feels like I skipped a year. Last year was not a productive year on the personal training front, so most of my items here are not really new. And I’m already about a half year late making a post like this, which means a few of these items might already be done or in flight.

So, what do I have in play this year? I’ve sort of skewed things a bit towards the blue team side of things last year, and that’s still the plan this year. I pride myself with having deep knowledge of red, blue, and forensics skills and I possess a strong belief that each plays and improves upon the others, whether in a team situation or as a long wolf.

Formal Training/Certifications

AWS Solutions Architect Associate certification renewal. I’ve done this once, so should be good to do again, but I’ll be consuming courses on Udemy and ACloudGuru in this pursuit. I truly thought about doing the Professional version of this, but I’d like more consistent hands-on AWS work before it.

AWS Security Specialty certification renewal. I’ve also done this once, and am not too worried about this one, but I do distinctly recall these questions were dense and tricky. As with SolArch, I’ll be using Udemy and ACloudGuru to prepare.

CISSP renewal. This is really about paying the fee, yet again. With all the other stuff I do, the CPE tanks are always full.

GIAC GCFA (FOR508) forensics certification renewal. This is also just paying the fee. But, I then need to carve some time out to go over the updated course materials and labs.

Antisyphon training courses. I’ve really liked the format of the BHIS/Antisyphon courses, and the cost as well. I plan to continue to take courses here as long as they have interesting topics offered. I’ve so far taken three, and while I’d just take them all if I could, here are some leading choices: Applied Purple Teaming (Ickler/Drysdale), Enterprise Attacker Emulation and C2 Implant Development (Thyer), Hacker Ops (May), and various others that tend to lean into Red Team stuff.

OffSec. A stretch goal. Since getting my OSCP some 5 years ago, I’ve wanted to get back and do some more of the advanced courses, labs, and subsequent certs that Offensive Security offers. I just haven’t done it yet. I likely won’t get to this in 2022, but I think in 2023 I want to look very hard at the annual subscription which opens up materials for all of OffSec’s certs.

Informal Training

BlueTeamLabs.online. BTLO is a sort of blue team themed lab and gamified ladder, much like HTB is for red team skills. The company behind this also offers courses for blue teamers, but I’m more interested in the labs to practice skills, learn new tools, and improve what I know through hands-on trial and error in a safe environment. This has exceeded my expectations so far, and I’ve even exceeded my own goals on the platform. I started out just wanting to learn some things and maybe make the top 100. Today, I’m trading off the global #1 spot with several others.

Practical Malware Analysis book and Reversing, debugging. Getting into and even successfully through the RE challenges on BTLO has whet my appetite for continuing down this path some more. I’ve long dabbled very lightly in reversing, debugging, and dissassembly, but never to a degree that makes me feel skilled at it. I’ve broken through some barriers while doing BTLO challenges, and I’m wanting to keep that ball rolling. I’d like to go through exercises in the Practical Malware Analysis and Malware Analysis Techniques books while also getting started in TryHackMe’s related areas. I also still have access to the Zero2Automated course set, but that seemed a bit beyond me when acquired a few years ago.

Microsoft Azure and M365 stuff. I namely want to just go through materials for AZ-900 & AZ-500, and then also MS-900 & MSSC-500 and other stuff in the SC-series. I don’t really plan to pursue any of the associated certifications, but I’m not entirely ruling it out, either. This is mostly to get more exposed and build foundations in Azure and M365 offerings as they become more and more ubiquitous in the enterprise. Very similar to picking up AWS skills a few years ago. Also plan to learn more about Azure Sentinel.

Splunk Learning. I use Splunk at work, and I’ve long put off the more formal courses. Splunk has recently re-organized their certification and learning offerings, and while I can’t say I think they’re good changes, I still want to plug through the material at some point. Much like MS stuff, I don’t necessarily plan to do the certifications. These courses are definitely only worth it if the business or Splunk credits pay for them. It’s otherwise better to just sign up for Boss of the SOC (BOTS) (free!) on a regular basis to gain some hands-on experience.

TryHackMe (THM). I’ve only briefly used this platform once, and just have not made the time or effort to get back here. I think now might be the time. I’ve almost fully completed BTLO, I don’t really want to go back to HTB yet, I’ve gotten up to where I want to be on PentesterLab. And THM is just a blank spot for me that I shouldn’t have let go so long.

PentesterLab. I still have a sub to this lab site, and while I’m mostly caught up on what I want, they still push out content enough to keep me coming back, particularly on the Code Review badge lately.

C2 & Attacker Emulation. Last year I took a course in using various C2 platforms, but didn’t feel like I got quite enough out of it on the first run. I’d like to wield my home lab a bit further and try more C2 platforms out and just gain more familiarity. If I achieve other things before the end of the year, this could be a nice break before 2023 activities.

Gentle Career Aspirations

I don’t normally do this, as I don’t want to suggest to potential employers that these are the only things I want to do, but it’s good to at least tell myself these things in case career opportunities land in my lap. But, in a way, doing these for work in the next few years would probably make me a happy employee (not that I’m not happy now, but it’d be exciting to look forward to and then learn and do):

• pentesting, red teaming, purple teaming…even just testing new exploit POCs
• C2 and attacker emulation to test and improve controls, both technical and response
• web app testing and other application/development security
• architect-level planning and design and advisement, configuration hardening
• ever-increasing hands-on in AWS and Azure/M365

Shortly after earning my OSCP I wanted to someday continue that push through the Cracking the Perimeter/OSCE certification as well. I never got around to it, and then OffSec retired that course while releasing AWAE(now WEB-300)/OSWE (and EXP-301/OSED), which I immediately also wanted to do. Part of my prep for a major certification is to Google up all sorts of reviews and posts about the certification and what other study materials and tips and insights other students found useful. This includes blogs, reddit posts, forum posts, and anything else that I could find or dig through. As such, I did plenty of this as preparation for the AWAE (WEB-300). I still plan to pursue this someday, but for now I wanted to share what I had compiled into my personal notes.

Some of these things I may have gained knowledge of through other less formal means over the past few years or just outright completed without really planning it, but AWAE is still pretty new and all of these resources are likely still relevant.

That said, never let too much preparation get in the way of getting access to the course and the labs for practice. You don’t just get sent off straight into an exam, and can always put that part off for later if some gaps in knowledge continue to linger.

Lastly, it should go without saying to click links below at your own discretion. All are external to this site.

My Goals

• level up my hands-on web app pentesting
• code review skills looking at vulnerabilities
• writing exploits for web app vulnerabilities
• actionable python (requests, etc)
• learn much more about .NET, C#, nodejs, php, and some more on java…enough to feel comfortable reading source code and tracing requests and parameters
• more familiarity with Visual Studio Code, debuggers

I do like to write out goals, as they do a few things for me. First, the goals help make sure I’m aligning my certification path and the preparation towards it with what I hope to get out of it. Second, it helps give me an idea what the certification path is all about, so that I can slot other possible preparation topics into it. In other words, managing expectations and summarizing the output.

This is my initial seeding of research and prep

• https://hub.schellman.com/blog/oswe-review-and-exam-preparation-guide
• https://medium.com/@klockw3rk/offensive-security-advanced-web-attacks-and-exploitations-awae-what-you-need-to-know-349933b72d24
• https://www.reddit.com/r/OSWE/comments/k0gcrm/awaeoswe_review_from_nondeveloper_perspective/
• https://blog.kuhi.to/offsec-awae-oswe-review
• https://www.reddit.com/r/OSWE/comments/ioj8gb/passed_oswe_taking_questions/
• https://medium.com/greenwolf-security/an-awae-oswe-review-2020-update-6d6ec7a80c1f
• Java coding, PHP, Microsoft MVC, C#, JavaScript, Python web requests handling
• WAHH Ch 19 and 21
• https://www.offensive-security.com/documentation/awae-syllabus.pdf
• https://forum.hackthebox.eu/discussion/2646/oswe-exam-review-2020-notes-gifts-inside (+thread)
• https://www.reddit.com/r/OSWE/comments/i0p187/failed_my_first_attempt/
• https://z-r0crypt.github.io/blog/2020/01/22/oswe/awae-preparation/
• Maybe I should do websec academy from port swigger first? Also pentester academy.
• https://www.reddit.com/r/OSWE/comments/jyr7sj/source_code_revie_methodologies/
• https://www.youtube.com/watch?v=F46tQww_IvE
• https://stacktrac3.co/oswe-review-awae-course/
• https://github.com/wetw0rk/AWAE-PREP
• https://github.com/timip/OSWE
• https://www.youtube.com/watch?v=ElZ7fFE9Gr4

Preparation Checklist

This is my reviewing of the above items and setting up some semblance of a plan. Considering what this cert is, I definitely don’t see myself signing up for this until the latter half of 2021. Worst case scenario, I am not entirely prepared, but sign up for the course anyway and either put off or fail the exam. Either way, I still come out of that with some learning, and extra time (and less stress based on deadlines), and a good idea of my next steps.

General things I need to do:

• learn what MVC and OOP really mean
• Python, writing small scripts to deliver exploits, handle requests <–should be comfortable with this
• C#/.NET
• nodejs/Javascript
• php
• java
• learn debugging and decompiling tools, dnspy, de-gui
• regex
• more SQL injection
• do various vulnerable web apps
• Visual Studio Code
• SublimeText
• brush up on various in-scope web app vulnerabilities types
• comfortable debugging the above on Windows and Linux, or at least aware of techniques

Actual things to do

• check out practice labs: https://twitter.com/trouble1_raunak/status/1361652466006315010
• book: WAHH ch 19 and 21
• course: portswigger’s web app academy
• course: pentesterlab
  • pentesterlabs XSS-to-RCE exercise is very helpful
  • do other exercises again
  • do code review badge again?
• challenges: https://edabit.com/
• challenges: do wetw0rk php challenges before lab!
• challenges: do wetw0rk javascript challenges before lab!
• vuln app: do DVWA
  • writing python scripts for DVWA exercises
• vuln app: do bwapp (or bee-box for preinstalled VM)
• vuln app: owasp juice shop
• vuln app: vuln web apps like ospaykj? oscode for nodejs and oscode for c#?
• vuln app: https://wiki.owasp.org/index.php/Category:OWASP_Code_Review_Project
• vuln app: nodejs https://github.com/snoopysecurity/dvws-node
• vuln app: https://github.com/appsecco/dvna
• challenges: pentester academy WAP challenges
• book: check red team/blue team books on the languages or tools to be used
• book: check any other debugging books I have for tools, ways to decompile or debug apps
• book: check any other web app books I have
• challenges: TJNull’s playlist for OSWE: https://www.youtube.com/playlist?list=PLidcsTyj9JXKTnpphkJ310PVVGF-GuZA0
  • HTB list: https://docs.google.com/spreadsheets/d/1dwSMIAPIam0PuRBkCiDI88pU3yzrqqHkDtBngUHNCw8/htmlview#
  • also HTB: https://github.com/s0j0hn/AWAE-OSWE-Prep
• challenges: some vulns to read up on or even practice: https://github.com/timip/OSWE
• challenges: https://hackxor.net/
• vuln app: OSCode for .NET framework? <–still not sure what this is
• read: https://owasp.org/www-project-security-knowledge-framework/
• compilation: https://www.yeahhub.com/vulnerable-web-mobile-os-projects/
• challenges: game of hacks http://www.gameofhacks.com/
• challenges: tryhackme – may be some relevant things here

Tools

• dnSpy – .NET decompiler
• Python requests and exploit building
  • know python requests inside and out, especially the session object
  • https://requests.readthedocs.io/en/master/
• de-gui for java?
• use Visual Studio Code regularly (many benefits; hotkeys and debugging, going to modules/references)
  • leverage Visual Studio Code SSH extensions
  • understand the launch_json files in Visual Code
• learn some SublimeText (for python)
• Burp (set scope, intercept requests, manipulate requests…)

Languages / major themes / skills

• c# .NET MVC
  • look into how MVC works
  • C# in an hour: https://www.youtube.com/watch?v=gfkTfcpWqAY
  • asp.net MVC in 1 hour: https://www.youtube.com/watch?v=E7Voso411Vs
  • https://codingo.io/reverse-engineering/ctf/2017/07/25/Decompiling-CSharp-By-Example-with-Cracknet.html
  • beg/advanced projects to review: https://hub.schellman.com/blog/oswe-review-and-exam-preparation-guide
    watch: https://www.youtube.com/watch?v=Xfbu-pQ1tIc&list=PLwvifWoWyqwqkmJ3ieTG6uXUSuid95L33
  • learn how to debug applications, echo variables, trace, decompile if necessary, etc. (interpreted=print, compiled=step)
• nodejs -> javascript
  • nodejs crash course youtube (traversy media)
  • javascript for pentesters (Pentester academy)
  • https://github.com/wetw0rk/AWAE-PREP/tree/master/JavaScript%20For%20Pentesters
  • beg/advanced projects to review: https://hub.schellman.com/blog/oswe-review-and-exam-preparation-guide
  • learn how to debug applications, echo variables, trace, decompile if necessary, etc. (interpreted=print, compiled=step)
• java
  • beg/advanced projects to review: https://hub.schellman.com/blog/oswe-review-and-exam-preparation-guide
  • https://techblog.mediaservice.net/2017/05/reliable-discovery-and-exploitation-of-java-deserialization-vulnerabilities/
  • https://github.com/wetw0rk/AWAE-PREP/tree/master/Understanding%20Java%20Deserialization
  • learn how to debug applications, echo variables, trace, decompile if necessary, etc. (interpreted=print, compiled=step)
• know how URL routing works in each of the languages
• SQL scripting
  • https://github.com/wetw0rk/AWAE-PREP/tree/master/From%20SQL%20Injection%20to%20Shell
• php
  • laravel (mvc) -> php – understanding routing
  • beg/advanced projects to review: https://hub.schellman.com/blog/oswe-review-and-exam-preparation-guide
  • https://github.com/wetw0rk/AWAE-PREP/tree/master/Understanding%20PHP%20Object%20Injection
  • https://github.com/wetw0rk/AWAE-PREP/tree/master/%5Cdev%5Crandom:%20Pipe
  • https://github.com/wetw0rk/AWAE-PREP/tree/master/XSS%20and%20MySQL
  • learn how to debug applications, echo variables, trace, decompile if necessary, etc. (interpreted=print, compiled=step)
  • learn how requests are routed
• learn what OOP is
  • https://github.com/wetw0rk/AWAE-PREP/tree/master/Simple%20Object%20Oriented%20Language%20Examples
• regex filtering/validation
  • https://regex101.com/
• django (mvc) -> python – understanding routing
• learn how to debug java, .net, php, and node on windows AND linux
• learning debugging, oop, mvc in java, nodejs, php, and c# (and how to read variables out of them)

General techniques to know about

• blind sql hunting (sqlmap)
• php type juggling
• common vuln examples: https://hub.schellman.com/blog/oswe-review-and-exam-preparation-guide
• reverse shells: https://highon.coffee/blog/reverse-shell-cheat-sheet/
• upload insecure files: https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Upload%20Insecure%20Files
• read examples here: https://stacktrac3.co/oswe-review-awae-course/
• read examples here: https://z-r0crypt.github.io/blog/2020/01/22/oswe/awae-preparation/

Pre-course things to revisit before purchasing the course

• read the footnotes and links, do the extra miles!!!
• define a methodology: blackbox the app first, then white box source code (grep/ngrep?)
• set up kali and note strategy
• read offsec faqs and guidelines for course and exam

Lastly, make a list of things from the above to review halfway through the course, and another list to review before scheduling the exam.

Back in the early 2000s I often used my blog to hold notes, links, and things I’d consumed or done or would check deeper into or read or do. Over the years, this activity sort of moved away from being in a blog, and more to my own private notes, or into Pocket (never to be seen again!). I feel like some of this is the result of the growing avalanche of information at our fingertips from 2000 until now.

I’ve gotten to the point where I kinda want some of that stuff cycled out of my private notes, but not always entirely lost. Something I could possibly still search and re-reference, without maintaining my own mini-encyclopedia of topical notes and links and to-do lists. Honestly, sort of the same itch that a diary or journal serves for thoughts and experiences…or other blogs and feeds. And the same sort of thing that will just go away when I do as the domain/hosting expires. (See, that’s the good part of hosted blogs, like blogspot and blogger, right? They’ll stay around?)

So, maybe I should start to empty out a bunch of my private notes into my blog here! I mean, on the other hand, why not? And while not private, it’s not like a bunch of folks will read most anything I put in here. 🙂 I feel like the days of personal blog-popularity are long gone anyway.

I used to also have a personal wiki I hosted, but never really did too much with, that I could resurrect for some things. Or just move that sort of usage over to Github Wiki.

I don’t think I’ll ever use a blog as a “to-do” list, as that is way too suited to a notes app. But, I can at least have a way to trim things off without feeling like I’m forever losing a resource or reference. Thereby maybe regaining control of my “to-do” list! Let some things go, ya know?

Anyway, I’ll see how this goes.

Regularly over the years I’ve had opportunities to give advice and direction on new or growing cybersecurity folks. I like to point out books, certifications, courses, resources, and most importantly other practical activities to grow knowledge and confidence as we all forge career paths. I’ve recently discovered and been playing on the Blue Team Labs (BTLO) platform which has, as the name suggests, blue team-themed exercises, challenges, and labs. There are nearly 200 labs and standalone challenges on the site, some of which are very difficult while others are relatively simple to solve.

Rather than discuss the platform itself at length, Dimitry Bennett wrote an article about his experience on the BTLO platform that basically says all that needs said on the topic.

But, there is still one thing I thought was daunting about the platform: Where to start when one is pretty new to cybersecurity? And this is the challenge any time I talk to someone else about where they’ve come from and where they want to go. All of us bring to the table different levels of experience, knowledge, and comfort with various technical and even non-technical topics. Some of us are very inexperienced with Linux, or have never written a program or script before, or maybe have done very little Windows system administration, but know Linux like no one’s business. What I wanted was a quick cheat sheet on what to suggest to students who wanted to quickly get their hands into the BTLO labs without immediately hitting walls.

This page is meant to help me prescribe labs and challenges to security analysts I encounter that are looking to build particular skills or experience what common SOC tier expectations exist.

I do want to make clear that the SOC tier expectations and levels of knowledge is just my take on the subject. I’m not going to be correct on all of these, nor will I be correct for how every organization/environment defines the job duties and expectations of each tier. I’ve just given this a best effort in the context of the whole of the labs, since I’ve gone through every single one, and my own experiences over years in the IT and security industry.

I also want to make clear that BTLO does allow students a chance to see what they’re getting into. Every lab has a difficulty level set to it, the date it was released, the general tools expected to be present, and even the number of solves that have been recorded since the lab was released. All of these can also help guide students to maybe avoid things they may find frustrating.

Here is a quick key to some of the columns in my table.

• Diff(iculty): Difficulty 1-10, 10 being hardest. My personal subjective value of how difficult this exercise is. Usually this is influenced by how much effort and knowledge may be needed to complete.
• SOC: My gut feel on what SOC analyst tier level I would expect to complete these exercises. Some tasks are pretty normal for tier 1 SOC analysts, whereas some of the more involved analysis may be reserved for higher tiers. I add a “+” if this task kinda overlaps into a higher tier. As an example, analyzing an image of live system memory or a PE executable file is typically reserved for more experienced analysts.
• Skills: My summary of the tools needed. If you don’t know Wireshark and want to learn more, then look at the easier Wireshark exercises. Of particular note, I make sure to list an OS if knowledge of or comfort using that OS is a huge help in solving the exercise. Adding “administration” to the OS is my way of saying that experience being an administrator of this server would be very helpful.
• Notes: My very quick reminder about what the main point of this is.

INVESTIGATIONS (by difficulty & SOC level)

CHALLENGES (by difficulty & SOC level)

NAME	DIFF	SOC	SKILLS	NOTES
D3FEND	1	1	Google (D3FEND Framework)	Looking up things in the D3FEND material online
ATT&CK	1	1	Google (MITRE ATT&CK Framework)	Looking up things in the ATT&CK material online
The Report	1	1	PDF reader	Looking up things in MITRE report (pdf)
Phishing Analysis 2	2	1	Text editor, Thunderbird	Analyzing a phishing email
Phishing Analysis	2	1	Text editor, Thunderbird	Basic phishing email analysis
Meta	2	1	Exiftool, OSINT	Analyzing some basic info from image files
Brute Force	3	1	Linux, text editor, grep	Analyzing logs of an RDP brute force attack
The Planet’s Prestige	3	1+	Email client, text editor	Analyzing malicious email plus office type attachments
Suspicious USB Stick	3	1+	Linux, peepdf, strings, VirusTotal, hex editor	Basic analysis of a malicious PDF
Powershell Analysis – Keylogger	3	2	Powershell, Text editor	Analysis of a malicious PowerShell script
Log Analysis – Privilege Escalation	3	2	Linux, bash	Identifying malicious commands in a bash log
Network Analysis – Malware Compromise	4	2	Wireshark	Answering some basic questions based on a pcap
Log Analysis – Sysmon	4	1+	Sysmon, Windows, Powershell	Using sysmon logs to answer incident questions
Malware Analysis – Ransomware Script	4	2	Text editor, Linux	Analyzing bash script for ransomware
Log Analysis – compromised WordPress	4	2	Linux, Apache logs	Analyzing a web attack from Apache logs on Linux
ILOVEYOU	4	2+	Windows, text editor, sysinternal, regshot	Dynamic non-PE malware analysis
Follina	4	2	Windows, OSINT, text editor	Analysis of multi-stage maldoc 0-day
Melissa	5	2+	Oledump, text editor	Non-PE malware analysis
Shiba Insider	5	2	Wireshark, Steghide, Exiftool, Linux	Unwrapping layers of hidden data and common artifacts
Network Analysis – Web Shell	5	2	Wireshark, Linux and attacker knowledge	Analyzing a Linux attack using a pcap
Malicious Powershell Analysis	5	2	Powershell	Parsing a Powershell script and basic obfuscation
Spectrum	6	2	Fcrackzip, Photorec, Audacity, efitool, steghide	Unwrapping layers of hidden data in less common artifacts
Employee of the Year	6	2	Photorec, scalpel, CyberChef, Linux, strings	Recovering and unwrapping various file types
Network Analysis – Ransomware	6	2	Wireshark, OSINT	Analyzing and even recovering files using a pcap artifact
Memory Analysis – Ransomware	7	2+	Volatility, Windows, OSINT	Mostly entry level volatility analysis of memory image
Paranoid	7	2	Linux	Analysis of linux logs to answer incident questions
Secure Shell	7	2	Linux, text editor, OSINT	Analysis of an SSH log
The Package	7	CTF	OSINT, CTF, Math/Python	Don’t recommend. Clever CTF-Like math riddle.
Reverse Engineering – Another Injection	7	3	IDA (Disassembler), Sysinternals, API Monitor	PE analysis and debugging, not entry level, but close to it for malware analysis anyway
Barcode World	8	CTF	Linux, Python	Decode flag from 9000+ image files; don’t recommend
Browser Forensics – Cryptominer	8	2+	Linux, FTK Imager, Javascript, Windows	Analyzing image file for browser artifacts
Reverse Engineering – A Classic Injection	8	3	IDA, Sysinternals, Windows	Static and dynamic analysis of a PE file
Injection Series – Part 3	8	3	IDA, Sysinternals, Windows	Static and dynamic analysis of a PE file
Squid Game	8	CTF	Steghide, image editor	CTF-like image stego; don’t recommend
Injection Series Part 4	8	3	IDA, Ghidra	PE analysis using debugger
Secrets	8	Red	Python, JWT, Linux probably	Red team web app attack against weak jwt
Veriarty	8	CTF	Hashcat, Veracrypt, Linux, Thunderbird, gpg	Recovery and decoding of files; don’t recommend
D-Crypt	9	CTF	Browserlings	Decoding a string several times with minimal guidance
P2SEC – Minigame	9	Red	Web App attacking, OSINT, exiftool, PE analysis	Unguided multi-stage mostly red team basics; long
Classical City	10	CTF	Sanity	Decoding ciphers – don’t recommend

This is my fifth year tracking my learning, training, and certification goals like this. I am approaching my 20th year in infosec and IT, and through many of those years I sort of idled or just did my job without a ton of real planning. So, now I do that sort of planning to keep me growing and progressing and owning the direction of my skills and career.

This year is already starting out slightly differently. It’s clear now that the world is a changing place with COVID-19 still impacting socialization and work. Also, even if good times, it does not look like my current Director at work has any interest in extensive training options that I’d brag about on here. Also, I’ve reached a level where there are not as many certifications for me to shoot for. All of this means my choices this year are more informal and geared around learning certain things, rather than specific exams to study for. Also, with all of the uncertainty floating around, this year is also looking to be a cheaper year for me personally as well.

Updated 2/9/2021: I added AWS Developer courses and AWS SysOps Associate courses. I also think I might be packing this again, since preparing for the AWAE is going to be pretty time-consuming.

Formal Training/Certifications

AWAE (WEB-300)/OSWE from Offensive Security – It’s been a while since I’ve done a formal course with OffSec, and I think it’s time to get back on one now that they’re revamping and expanding their offerings. What I’ll likely do is spend some time looking at reviews and other testimonials to get an idea of some pre-course topics to brush up on, and then clear a few months of personal time to dive hard. I’d actually expect to do this exam as well.

Applied Purple Teaming (WWHF/BHIS) – I almost took this course last year, but backed out of it. I enjoyed the value of the course I took from this group last year, so figured I’d check in again this year on it.

Informal Training

Pentester Academy – I still have this subscription, and I’d like to get back onto some of these courses again. I still have SLAE on my list… I also would really like to commit to their red team labs, but don’t want to quite hold myself to it yet.

PentesterLab – I still have this subscription as well, and I’ll carve out some time at some point to progress further on badges.

Zero 2 Automated malware analysis course – I meant to start this late 2020, but life got in the way. I’m adding it to this list to make sure I get it going again.

Azure and M365 courses (900, 500 levels) – Furthering my Azure and cloud knowledge, I plan to take some courses on Azure and Microsoft 365, focusing on the fundamental and security tracks. I don’t have plans to sit for these exams, but I could always decide to do so.

AWS Developer Associate and AWS SysOps Associate – While I don’t necessarily plan to take these associated certifications, I would like to sit down and just casually run through 1 or 2 courses on each subject. I feel like there are things I can learn and use from these two. I’ll probably lean towards looking at offerings on Linux Academy / ACloudGuru or maybe PluralSight if they have a free weekend.

Other

Other one-off courses – I have a bunch of free and acquired courses in my possession that I need to get through at some point. It’s really about sitting down for a weekend or a series of nights and just going through them. No real intense time-spend, but enough to gain some knowledge. Courses like those from Port Swigger or Mudge or Autopsy or other topics.

Books – I continue to have a backlog of books to go over or skim through.

Python, .NET – I’d like to get some introductory exposure to .NET/C#, but this might be asking a lot of me without actual projects on tap to perform.

Certs to renew

CISSP – I’ll renew this again.

CCNA Cyber Ops – This lapses this year, and I have no plans to renew it.

The 2020 year was not one of the best years for a variety of reasons. My personal productivity was definitely a little lower than past years, but overall satisfying enough considering what a weird and crazy year this was for everyone. Here’s what I did or did not get accomplished.

Last year I started a cloud-focused learning journey by earning my AWS Cloud Practitioner and AWS Solutions Architect Associate certifications. I completed this push by earning my AWS Security Specialty certification in May. This was an interesting experience as I tested from home as COVID-19 restrictions changed how we work and live. This was an interesting journey as I feel like my certification is slightly ahead of my practical hands-on experience within AWS. But, we have to start and proceed somewhere!

That certification would prove to be the only one I would earn on the year. I opted not to pursue another “remote” certification, plus there appeared to be no interest in having a training budget at work any longer, which meant no SANS course for this year nor any real reason to give ISC2 more money.

In the later half of the year I did take a 16 hour course hosted by Wild West Hackin’ Fest: Breaching the Cloud led by Beau Bullock of BHIS. This was an excellent course over 4 days and my only regret was not taking full days off for these. Half days kept me pretty busy! This course flowed nicely into my recent forays into bolstering my cloud experience, particularly with Azure. And the focus on the offense side gave me a different perspective than my previous defense/builder studies. I would love to go through this material again for further reinforcement and practice in 2021.

I also spent a good amount of time in Pentester Lab this year, completing out quite a few of the badges: White, Yellow, Blue, Green, Orange, Serialize, Intercept, Android, PCAP, Essential, and Unix. This was a flurry of activity and learning this summer. I made progress into other badges, but have plenty of content to get back into as I get time. Still, this was a significant outlay of time and addition to my skills and exposure to make this a highlight of my year.

I also did some online playground activities as well. I solved most of the challenges through the summer on the BHIS Cyber Range. I participating with a work team in the Splunk Boss of the SOC competition as part of the Splunk.conf conference. And I also was invited into and poked around Offensive Security’s Proving Grounds beta, which gave me a chance to stretch off some rust on my penetration testing of boxes.

Overall, that was mostly my year. It didn’t feel as productive as other years, but I’ll give it a pass considering 2020 was quite a shift and change for many reasons.

There’s a lot of noise on Twitter. But sometimes, there are threads that harken back to the day of quality hacker and infosec forums. Like this one from @InfoSecMBz:

I love these sorts of thought exercises.

Going from next to nothing for 5,000 servers, and getting to real configuration management is going to be a multi-year process, and probably encompassing a full lifecycle for those particular machines. It just is, unless someone has the go-ahead to scorched earth burn it down and rebuild, or to slam in a standard and deal with the broken assets and resources for a few years of pain (and burnout of admins).

And let’s just be real here if we’re talking to this client. There are mature shops who do lots of things correctly, but still have poor configuration management. In a made-up scale of 1-10 on the road to mature IT and security practices, configuration management is probably around 4-5 to start, and 7-8 to really own.

Below are some of my bullet items. And yes, I know there’s a whole thread to cheat from, but in true thought exercise spirit, I’ve tried to minimize spoiling myself on all the other answers right away.

0. Discuss the scope, deliverables, definitions. Wanting to do “configuration management” can mean different things, and for a project that could take years, the specifics really need to be discussed.

• For instance, is the desire to have a hardened configuration baseline?
• Or just a checklist on how every server is built at a basic level?
• Is it necessary to know and profile all software installed?
• Does this include configuration management for all features, roles, software? E.g. IIS/Tomcat/Apache, etc.
• What is the expectation to build on-going processes, audits, checks to ensure compliance? Is this even about compliance?
• What is the driver for the customer asking for this, is this to adhere to a specific requirement or to eliminate an identified risk to operations and technical debt? Someone read an article or talked to a peer?
• What is the vision of the future? Someone at some point needs a 1-year, 3-year, 5-year vision of how the environment is managed. “In the future, I want all servers to have a documented build procedure and security configuration automatically enforced continuously and all changes known and tracked.” Vision statements help contain scope, determine deliverables, and help define success.

I would start by breaking out some of the layers of “configuration management.” My assumption here is this post will cover the first two items, and leave the others for future maturity.

• There is OS level configuration management, including patching.
• Then there is management of software.
• Then there is configuration management of things that live within the OS (software, features, services, server components..).
• And then there is configuration management of custom applications, code, web apps.
• Lastly, I also consider networking devices to be a separate discussion.

If a customer truly does not know what they want, I would say what they want is threefold:

• They want to know their inventory/assets.
• They want to patch and know their patch coverage metrics.
• They want to know how to build/rebuild their servers to minimize ops risk/cost.

00. Plan the project. At this point, there should be effort made to plan out the project. The items listed below are not meant to be done 1 by 1 and only moving to the next after finished the first. There’s no way that project will complete successfully. Instead, many of these items can be run in parallel for a long period of time. There should also be milestones and maturity levels that are achieve as they progress. And there are questions of how to move forward. Should we tackle the whole environment at once, or should we tackle small swathes first. If we do a small group first, we can more quickly produce proof of concepts, and possible pull in other lines of servers later on. Or maybe we just stand up a good environment, and as server lifecycles kick in and servers fall off, their services could be brought back up in the “good” environment. All of the above are ways to go, and an idea should be formulated at this point on options to move forward and track progress.

1. Inventory. This needs to start with some level of asset inventory to capture what is present in the environment. What OS and version, where is it located on the network, what general role does it play (database server, web server, file server, VM host…), physical or virtual, and a stab at who the owner of the system is. This should be a blend of technical and non-technical effort and is meant to be broad strokes rather than fine-grained painstakingly detailed. On the tech side, scanning the known networks*, looking at firewall logs, looking at load balancer configurations, looking at routing tables and arp tables, dumping lists of VM’s from VM hosts. On the non-technical side, interviews with staff who own the servers and interviews with staff who use resources that need to be known. All of this information will fuel further steps. And I want to stress, that very few of the subsequent steps will see true success without this step being taken seriously.

(* This may be a good time to also have the customer introduce a baseline vulnerability scanning function. There is a lot of overlap here with a vulnerability scanner that scans the network for assets, tries to log in and do various checks, and enumerate patch levels and software installed. Or it might be time to implement a real asset CMDB or other system. Keep in mind each OS family will need some master “source of truth” for asset inventory.)

From here, we can start splintering off some additional tasks to run in parallel or otherwise. For the sake of simplicity, I’ll just put these in a rough order, but some things will start together, and end at different times.

2. Determine external accessibility. The point here is to quickly know the most at-risk systems to prioritize their uptime, but also prioritize getting them in line and known. Most likely these are the systems most needed to be up, recoverable, and secure. This will require interviews, perimeter firewall reviews, load balancer device reviews, and even router device reviews to map out all interfaces sitting on the public Internet, and how those map back to actual assets on the internal networks.

3. Start making patching plans. In the scenario above, they don’t know a thing about security. This tells me they likely don’t have good patching. And this is going to have to be dealt with before tackling real configuration management. Based on the OS versions in play in the environment, plans of attack need to be made to automatically patch those servers. If this is a Windows environment, for instance, WSUS or SCCM or some other tool needs to manage the patching. This step is really about planning, but eventually it will get into deploying in phases as well. Don’t overlook that major service packs and version upgrades technically count as patches.

4. Find existing documentation and configuration practices. Someone’s been building these servers, and something has been maintaining them to some degree. Existing practices and tools should be discovered. Staff who build servers from a checklist should expose those checklists. If they’re done by memory, they need to be written down. If some servers are Windows and there is a skeleton of Group Policies, those need exposed. If they are Linux systems and some are governed by Puppet, the extent of that governance needs exposed. If possible, start collecting documentation into a central location that admins can reference and maintain and differences can be exposed.

4a. Training and evangelism. At this point, I would also start looking at training and evangelizing proper IT practices with the admins and managers I interview. From a security perspective, I find a good security-minded sysadmin to be worth 3-4 security folks. Sysadmins help keep things in check by design. They’re the ones who will adhere to and promote the controls. If the admin teams are not on board with these changes, all of the later processes will break down the moment security isn’t constantly watching.

5. Change management. Chances are this environment does not have good change management practices. At a minimum for our purposes at the start of this big project, we need to know when servers are stood up and when they are decommissioned. This way we have a chance to maintain our inventory efforts from earlier. If there is no process, start getting someone to implement one (either manual announcement, to automated step in deployments, to picking them up with the network scanning iterations). One side goal here is to use earlier network scanning for inventory to compare against what is exposed through change management. If a server is built that is a surprise, it can be treated as a rogue system and removed until change management authorizes it. This process helps reduce shadow IT and technical debt due to unknown resources in play. It also helps drive the ability to know what percentage of the whole is covered by later controls and processes. If you don’t absolutely know the total # of servers, you can’t say what your patch % is, for example!

6. Analyze inventory. At this point it should be appropriate to analyze the inventory and see what we’re dealing with. How many families of OS are present, what versions are they, what service pack levels, and what patch levels. Which systems are running unsupported Operating Systems. We should have some pretty charts showing the most common OS’s in place. And these charts can help us direct where our efforts should focus. For instance, if 80% of our environment is Windows, we should probably focus our efforts there.

We should also start looking at major types of servers, such as web, file, storage, database, and other usage we have and those percentages.

7. Baseline configuration scan for each OS family/version. This might take some effort, but this is about seeing the damage we’re looking at. This does not have to be a scan that gets every server, but from the inventory analysis above, we should be able to pick out enough representative servers to scan with a tool we introduce and get an idea of what our current configuration landscape looks like.

Bonus points on this item if a standard has been identified and used as the comparison to see drift, but I wouldn’t consider that necessary quite yet. This is all about getting a baseline scan that we can look at a few years from now and see just how much improvement we’ve made.

8. Interview owners and expand inventory data. Start chasing orphaned servers (shadow or dead IT?) and get them assigned an owner. This also helps determine who is really accountable for various servers. This usually isn’t admins, but the managers of those admins who will be the ones who will end up needing to know about changes and authorize changes such as patches and configuration changes. Try to figure out if certain owners will be easy to work with, and others will be difficult, to help prioritize how to tackle getting server in line.

Just to note, at this point, we’ve still not really made any changes or done anything that should have impacted any services or servers. That will start to change now.

9. Patch. Expand change management scope to include patching approval and cadence. Synthesize asset information on system owners and patching capabilities. Determine a technology and process to handle OS patches, and start getting them deployed. This may take several iterations and tests before it starts moving smoothly, which may be half a year for so many servers. Try to make sure progress can be tracked as % of servers patched and up to date compared against your full expected impacted inventory.

10. OS Upgrades. At some point in this large environment, systems will need to be replaced or upgraded, or there are no longer patches available for is (unsupported). Start to plan and document the process to do server upgrades or replacements. This can be wrapped into lifecycle management practices. The changes from this tie into the change management process. And if you have really good build documentation for base servers, but also the role for the servers you’re upgrading, you can morph server “upgrades” into server “replacement with newer fresh versions.” This helps combat technical debt that comes from servers upgraded over many years where no one knows how to actually build that server if it got dumped.

11. Compare baseline against configuration knowledge. Think about comparing against a known secure configuration standard to find the delta. CIS benchmarks are great for this, and this step is only about comparing against something, but not yet making a process to get closer. For the most part, this is about comparing your baseline against the configurations you think your servers should be meeting based on interviews and how staff has built servers in the past. Actively start leveraging change management and configuration management tools to make changes in non-compliant servers. A major deliverable from this step should be your first versions of configuration standards.

Only now do we get to actual “configuration management.”

12. Implement configuration management capabilities. For the largest and easiest swaths of OS family/versions, start implementing configuration management tooling. For Windows, make sure they are joined to the domain, analyze and standardize Group Policy. Create a starting point and get missing systems in order. For Linux versions, get them into and managed by Puppet or some other solution.

13. Enforce standard server builds. The situation here is that servers are now patched properly, configuration enforcement tools are in place, and build processes are exposed. This means teams and admins should only be building servers based on known configurations and standards. This is a people process and making sure all admins are doing things the same way.

14. Implement process to improve the configurations. There are many ways to do this, but it all comes down to having a process to choose a configuration setting to change, test it, track it, announce it, and implement widely. This can be based on an end goal configuration, or just picking various settings and making them better; making systems more hardened.

Keep in mind this does not mean having perfectly secure configurations. You can try that, that’s fine, but it’s about having a process to continuously move towards that direct.

Further steps will tackle the other scopes, such as installed software, roles/features, settings within installed software, etc.

Lastly, this project should only be walked away from under the awareness by the customer that most of the above steps are introducing new functional processes that have to remain in place continuously in order to succeed. Once these processes are neglected, that function will break down, configuration drift will occur, and progress will reset.

Last week, I took and passed the AWS Security Specialty certification exam. This is an advanced “specialty” certification offered by AWS centered around, surprisingly, implementing and managing security within the AWS cloud platform. This certification until recently required passing one of the Associate level exams, but today you can skip right to it if you think you can pass it. To renew, you only really have the option to take the exam again, at a reduced price.

Background and cloud path

I started my AWS cloud path about this time last year for two reasons. First, I wanted to stay current with my own skills and AWS wasn’t something I had the pleasure of supporting or playing in yet. Second, my company is in the process of moving workloads to AWS, and I wanted to keep up. In August of 2019, I passed the Cloud Practitioner. In September I passed the CCSK. And in December 2019 I passed the AWS Solutions Architect Associate. I started from Practitioner because I honestly was pretty fresh into AWS technologies and services, though not foreign to the concepts of the cloud after 18 years of IT experience. I could have tried to skip to the Security exam, but as someone painful fresh to working within AWS, I chose to do the Solutions Architect first, as many of the topics are foundational to the Security exam.

My goal has been not just to become aware of and conversant with AWS technologies, but to pave the way for hands-on pursuits, both personal and on the job. It’s been a bonus that the stars have aligned enough to allow me to learn on the job and build out a greenfield environment in AWS as we migrate into it full sail. I want to be able to understand how things are built in AWS, maintained in AWS, and secured in AWS so that I can begin to break it from the offensive side and then response to such activity efficiently. In the end, I want to be able to advise others on proper AWS security topics, both at a high level and also in the trenches.

And it’s a little self-serving; it’s a nice career safety net as well, much like my sysadmin skills and experience are to my infosec career.

Study plan

For the Security Specialty, my study plan started by learning the concepts for the prior exams. I kept a sick looking Gantt chart of my study plan efforts, but the Security specialty was definitely pretty stream-lined.

I also must mention that my original goal to pass this exam was Q1 2020. Unfortunately, COVID-19 concerns shut down testing opportunities and really stole some of my study time away, which elongated my efforts a bit. Thankfully, I don’t have other major plans for formal studying or certifications this year, so I had some personal wriggle room to push this into Q2.

As with other efforts, I started with A Cloud Guru’s course on the Security Specialty. This course is a little short on covering all the things you need, and it blasts through it quickly. And I have the same issues as I did with the Solutions Architect course where it’s just not polished, there’s plenty of mistakes that are left in the material, and it’s not nearly complete enough to rely upon to pass the exam. Still, it makes a relatively OK intro to the material. I’ll probably revisit this as review if I should renew the certificate in 3 years, since it requires taking the exam again.

My main effort centered around the related Linux Academy course by Adrian Cantrill. I really liked this course, and felt pretty darn prepared for the exam after it and after taking the Practice Exam (I scored 88% on my third and finally take of it.) This course is well over 40 hours, and does a good job being broad and deep enough to properly prepare for the exam.

Lastly, I spent time reading whitepapers, documentation, and FAQs off the AWS site on all of the security-related and core services I could. More importantly, I strongly suggest browsing the AWS security blog posts from 2017 through the end of 2019 to see scenarios and tutorials on how to do things like properly secure your root user, or incident response steps for a compromised key, or how to troubleshoot CloudWatch connectivity issues and various other common or weird scenarios. These scenarios and understanding how these work is extremely useful for the exam. As a bonus, truly read through these and follow along on the actual steps, or even recreate them in your own words.

I didn’t get a chance to use it, but if I had failed my exam attempt or started later than I did with my studying, I would have probably purchased the Practice Exam from Tutorials Dojo. My experience with Jon Bonso’s content was positive enough for the Solutions Architect that I would blindly pitch my money into this one had it come out earlier

The at home experience

I took my exam through Pearson Vue using the at home option. I thought the exam itself was stressful and difficult, but I have to say I think the at home experience was even more stressful to me. See, I live in an apartment and some of the rules of the at home component dictate a strict no sound posture. In fact, you’re not really supposed to even look away from the screen or make noise on your own! Thankfully, I have no idea what the real limits are, as I had absolutely no interruptions, noises, or contact with the proctor during my 1.5 hour exam duration. But, throughout my exam I dreaded noise in the hallway or a door shutting that would cause a disqualification!

Being in an apartment, I did quite a lot to prepare. I covered bookshelves, moved everything away from my dining table, and made an effort to minimize anything that needed scrutinizing. I had a USB web cam next to my laptop, but I was asked to move it to the top of the laptop anyway. I probably could have just used my built-in cam on the laptop. I never did hear anything from the proctor, only chat, and I have no idea if the proctor could hear me, as I typed my responses in and echoed them verbally as I did. The biggest instruction I had was to make sure a wall-mounted television in front of my was unplugged, which I had to quickly uncover the outlet and power cable to indeed show it was unplugged.

And while I apparently had no issues, it was definitely not relaxing taking the exam. Even halfway through, my head, neck, and shoulders were hurting from being all tensed up, and my eyes really yearned to just look up and afar for a bit while in thought on many of the questions. I’m pretty sure 30% of my mind was on my actions/behavior and not on the exam.

I imagine this is far, far better in a home where you can maybe go to a relatively empty basement room and keep pets/mates from making noise elsewhere, and not have to worry about much.

The exam

Basically, this exam sucks. I mean, it’s a good exam and really tests your knowledge of not just knowing how things work, but really digging deep to make sure you know or have done the steps in the many scenarios presented. I would estimate that maybe 40-50% of the questions were choose 2 or choose 3 answers. I’d guess about 70-80% were scenarios, and almost nothing was straight definitional.

Most questions were also pretty long to read and digest, and I found myself re-reading whole sections before even getting to the answers. And often the answers were lengthy as well. It was a splash of cool water when I hit short questions with short answers!

I also usually get done with an exam and I retain a litany of questions or items that tripped me up or I was happy to see, but in this case, I walked away at the end and had but one item to look up, and even then I couldn’t remember the context of the question!

Overall, I really liked the exam for what it tested against. This isn’t a light exam or something you can swing into with painfully little experience. You really have to understand how to do these things to get through it. I scored a 940 on it, and I’m extremely surprised and satisfied with that score.

That said, it should be kept in mind that this is still a multiple-choice exam. Even if a question is a big fat question mark, often one or two options will bubble up to the top and help formulate a decent guess.

What’s next?

Honestly, for AWS stuff it’s really about practical experience at work and on my own that is next. I will probably check out the Developer or Sysops Associate certs in time when I can apply those to renew the others. But otherwise, I have what I came for on the formal learning side of AWS and my immediate path to the dark side is now complete.

For cloud stuff, I’ll probably look at learning more about Azure through Linux Academy on my own time. And I’ll start focusing on topics that pertain to security and even penetration testing cloud deployments.

For security stuff, most of the rest of my 2020 was planned to be pretty informal, which works out well considering COVID-19 has changed things and put other things on hold so dramatically. I have a backlog of courses, tutorials, and other learning activities to do that would eat up years, so I want to chunk away at the juicier parts of that.

I keep a lab at home, but I honestly don’t upgrade the underlying guts of it very often. I really got sick of rebuilding things in my early years as an IT admin. I like when things work, and as long as they keep working and my threat profile remains the same, I tend to keep the underlying infrastructure pretty much untouched. I’d rather wrestle and play with the VMs that run on top of things, ya know?

Typically, my upgrades come about when I change hardware. Or when something doesn’t work. Tonight, I tried to install Kali 2019.4, but I had some hard, unknown stops that felt like vm host limitations. Rather than fight with it, I thought I’d upgrade my VMware server.

My main lab is an Intel NUC device running a VMware ESXi 6.0 bare metal install. I really dislike the web management interface in modern VMware, so I’ve clung to 6.0 for about as long as I’ve been able to. I also really like having the option of running consoles from the vSphere Client application.

Upgrading the ESXi installation is about as easy as it gets. I verified some instructions and then went to town.

esxcli network firewall ruleset set -e true -r httpClient
esxcli software sources profile list -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml | grep -i ESXi-6.5.0-2019
# I decided to choose ESXi-6.5.0-20191204001-standard and move on!
esxcli software profile update -p ESXi-6.5.0-20191204001-standard -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

[InstallationError]
[Errno 28] No space left on device
vibs = VMware_locker_tools-light_6.5.0-3.116.15256468
Please refer to the log file for more details.

Well, that sucks, but I definitely have room on my device. A quick search showed me that this is an updating error that I could fix by letting ESXi use diskspace as swap when needed, which it apparently needed for the upgrade. A quick visit to Manage > Settings > System Swap got me squared away and the above update command succeeded in surprisingly minimal time. Next, I rebooted the device. Then, I returned the local firewall option to false and I logged into the management console and confirmed my version was 6.5.

I then installed the VMware Remote Console application in order to use a standalone app instead of browser windows for console access. Either way, I dislike them, but the standalone app is the lesser evil. I downloaded version 11.0 from VMware directly, but it can also be grabbed when first trying to open a remote console off a VM.

My core VMs fired up just fine (pfsense and a jump box), I was then able to install Kali 2019.4 without issues at all. I have no idea what the real fix was, but I’m glad that a mere ~30 minutes later I’m past the issue.