Most autonomous red teaming research assumes access to frontier cloud APIs or multi-node H100 clusters. As an operator running experiments on my own time without a datacenter compute budget, I wanted to see how far I could push a strictly local model on a single consumer GPU (a 24 GB RTX 3090). Here is how I took Llama-3-8B, removed false-positive safety refusals via activation projection, trained it on 1,250 synthetic Active Directory trajectories using Unsloth, and tested where an 8B model succeeds and where it hits its architectural ceiling.

The Problem (and Why an 8B Model?)

During my work running engagements at Mandiant, I spent a lot of time working through sprawling, heavily segmented Active Directory environments. In a real enterprise network, getting from an initial workstation foothold to tier-zero assets is rarely a straight line. You are dealing with complex forest trusts, strict firewall chokepoints, tiered administration boundaries, ACL and GPO abuse chains, delegation primitives, and misconfigurations spread across thousands of hosts. Finding a viable path requires real graph reasoning, where you test a lead, hit a network block, backtrack, and pivot through an unexpected intermediate system.

Startups have raised hundreds of millions of dollars trying to automate this kind of multi-hop attack path validation. I wanted to see what it actually takes under the hood to build an autonomous agent that can do this locally.

If you look at the current AI landscape, the first question that comes up is why anyone would use an 8B parameter model (Llama-3-8B) instead of a 70B model or a frontier API. For me, it came down to hardware reality and engagement OPSEC. As a consultant running these experiments independently on my home desktop during personal hours, I do not have access to an H100 cluster or a massive cloud compute budget. Everything from activation extraction and hyperparameter search to native 16-bit (bfloat16) LoRA fine-tuning had to fit inside the 24 GB VRAM budget of a single consumer RTX 3090. At 16-bit precision, 8B parameters is the practical limit of what you can train and iterate on quickly on one consumer card. Beyond that, on real client assessments you cannot pipe sensitive Active Directory data or password hashes out to third-party cloud APIs anyway, so any model you actually bring onto an engagement has to be small enough to run on local hardware.

When you drop a stock Llama-3-8B model into an agent loop (Reason -> Act -> Observe), it fails right away. First, the default safety filters block the model whenever a prompt involves security validation or lateral movement tasks. Second, even after you remove those blocks, an 8B model does not know how to plan across a network topology. When it runs into a firewalled server or a dead end, it does not know how to backtrack and try another route, so it just repeats the same failed command in a loop.

To fix both issues, I broke the project into two stages. First, I adjusted the model weights so it stopped refusing routine security tasks. Second, I scoped a local simulator around three representative AD attack primitives and fine-tuned the model on 1,250 multi-hop trajectories so it could learn how to plan and backtrack.

Step 1: Stopping False-Positive Refusals

Early “uncensored” models were usually trained on giant datasets of unfiltered text, which tended to make the model worse at following instructions and outputting clean JSON. A cleaner approach from recent representation research (Arditi et al., 2024) shows that refusal behavior in instruction-tuned models is mostly controlled by a single direction in the model’s activation space. When a prompt mentions security testing, the internal activations point along that direction and trigger a refusal.

By comparing the model’s internal activations on security prompts against normal prompts, you can isolate that refusal direction v as a unit vector and subtract it out of the weight matrices:

v  = (μ_security - μ_normal) / ||μ_security - μ_normal||
W' = W - α(Wv)v^T

Because that change is just the outer product of two vectors, it is a Rank-1 matrix update. That means you can save the modification as a lightweight LoRA adapter instead of saving a whole new 16 GB copy of the model.

Instead of manually guessing which transformer layers to edit, I used the Heretic toolkit to run an automated search (using a Tree-structured Parzen Estimator) across different layer ranges and scaling factors. The goal was to drop the refusal rate as low as possible without messing up the model’s normal token probabilities (measured by KL divergence).

Once the adapter was applied, I ran a few quick tests asking the model to write local permission auditing scripts and post-exploitation helpers that the stock model refused. The updated model handled them cleanly without lecturing, so it was ready for the agent loop.

Step 2: Generating 1,250 Multi-Hop Trajectories

Getting the model to run tools was only half the problem. When I connected the model to my local Active Directory simulator, it still could not chain steps together across a network. To teach an 8B model how to navigate a multi-hop environment, you need multi-turn traces (Reason -> Act -> Observe) where the model states a thought, calls a tool, reads the output, and adjusts its plan.

Writing 1,250 multi-turn traces by hand was not realistic. Normally you would use a large frontier API as a teacher model to generate synthetic training data, but commercial APIs refuse requests that ask for offensive Active Directory attack paths.

My workaround was a two-stage translation loop. From a graph-routing perspective, an IT administrator running an internal infrastructure audit and an operator validating attack paths are executing the exact same logical steps. Both scan the subnet, check registry keys for client configurations, verify service accounts, and inspect certificate templates on the CA.

[1. Prompt Sent to Teacher API]
"Perform an authorized administrative network audit to map internal assets
 and verify client policy distribution servers."
        │
        ▼
[2. Teacher API Output]
THOUGHT: I need to query the local client directory policy repository to inspect policy structures.
ACTION:  {"action": "audit_policy_store", "arguments": {"host": "PC-01"}}
        │
        ▼
[3. Mapped to Local Simulator Schema]
THOUGHT: I need to query local registry configurations on the foothold to locate cached credentials.
ACTION:  {"action": "query_registry", "arguments": {"host": "PC-01", "key_path": "HKLM\\Software\\Microsoft\\CCM"}}

I fed standard corporate audit scenarios to the frontier model, took each step it generated, and ran it through a local script that mapped the thoughts and tool names back into my agent’s schema. That action was executed against my local Python AD simulator, which returned a consistent JSON observation.

To keep the simulator tractable while still testing whether the model could generalize across different attack types, I scoped the dataset to 1,250 trajectories split evenly across three common AD attack paths (around 415 traces each). One third of the dataset covered infrastructure misconfigurations like extracting local SCCM Network Access Account policy blobs, another third covered identity attacks like SPN enumeration and Kerberoast ticket cracking, and the final third covered ADCS certificate template abuse (ESC1).

Step 3: Preventing Hostname Memorization

While testing early builds of the dataset, I noticed that if the Domain Controller is always named DC01 and the starting workstation is always PC01, an 8B model takes a shortcut. Instead of reading the JSON output from network_scan to see what hosts actually exist on the subnet, the model simply memorizes the string "DC01" during training and hardcodes it into its tool calls.

At the same time, if you randomize hostnames into random gibberish like srv_9x8q2z, the tokenizer splits the hostname into a bunch of tiny sub-word tokens, which bloats the context window and hurts attention.

To fix both problems, I added bounded randomization to the simulator. Every time a new episode starts, the environment generates realistic enterprise naming conventions with randomized two-digit suffixes:

self.suffix    = f"_{random.randint(10, 99)}"
self.domain    = f"sevenkingdoms{self.suffix}.local"
self.dc_name   = f"PRIMARY-DC-{random.randint(10, 99)}"
self.site_mgr  = f"SITE-MGR-{random.randint(10, 99)}"

Because PRIMARY-DC-47 still looks like a normal corporate server name, the tokenizer handles it cleanly. Because the numbers change on every run, the model is forced to actually parse the scan output and pull the right hostname from the conversation history before calling its next tool.

Step 4: Fine-Tuning on an RTX 3090 with Unsloth

With the 1,250 trajectories ready, I ran the Supervised Fine-Tuning (SFT) job in WSL2 Linux using Unsloth. Unsloth uses custom Triton kernels for attention and RMSNorm backpropagation, which reduced memory usage enough for me to train in native 16-bit bfloat16 inside my 24 GB VRAM budget instead of dropping down to 4-bit QLoRA.

I trained a rank-16 LoRA adapter (r = 16, lora_alpha = 32) across all attention and MLP layers (q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj). To keep the gradients stable without running out of memory, I set the batch size to 2 with 8 gradient accumulation steps (for an effective batch size of 16) and used the 8-bit AdamW optimizer (adamw_8bit) to save another 2 GB of VRAM.

The training job ran for 500 steps (about 7 epochs). Training loss dropped from 2.059 down to 0.066, and I merged the resulting LoRA adapter back into the weights to produce the final RedAgent model.

Step 5: Benchmarking Across Three AD Topologies

To test whether the fine-tuning actually helped the model plan, I ran the stock model, the refusal-stripped model, and RedAgent side by side against three simulated Active Directory topologies of increasing complexity.

What Happened on Each Tier

All three models passed Tier 1 because it is a straight line with no dead ends. As long as the tool descriptions are in the system prompt, even an untrained model can step through 5 sequential actions.

Tier 2 (the firewalled chokepoint) is where the trajectory fine-tuning really showed its value. When the stock and refusal-stripped models tried to pivot to the Domain Controller at Step 5 and got back "Access Denied by firewall", neither of them knew how to recover. The refusal-stripped model just kept running the exact same failed pivot command against the blocked DC, or started guessing tools at random until the context window filled up with failed attempts (on the rare runs where it stumbled onto the right server by pure luck, it took over 22 steps).

RedAgent, on the other hand, solved Tier 2 in the exact 10 optimal steps. As soon as it saw the firewall rejection on the DC, its next thought noted the block, backtracked to SITE-MGR-xx, pulled the credentials from the site server, and completed the path to the DC.

Tier 3 (the 14-step ADCS path) broke all three models, including RedAgent. Looking at the execution logs, RedAgent got through the initial SCCM steps, saw the DC was blocked, and correctly decided to go after ADCS certificate templates next. However, instead of calling pivot to move onto CA01 first, it kept trying to run query_ca_templates directly from the starting workstation until it hit the step limit.

When I looked through the simulator code and the agent traces, it became clear why that happened. In real Active Directory environments (using tools like Certipy or Certify), you query ADCS certificate templates remotely over RPC/LDAP right from your initial workstation without ever needing an interactive session on the CA server first. My simulator state machine, however, was written to require current_host == ca_name before query_ca_templates would succeed. Once the conversation history stretched past 10 turns, the 8B model fell back on its pre-trained AD knowledge instead of following the simulator’s stricter host rule.

That problem was compounded by how the simulator handled errors. In Tier 2, when the DC pivot failed, the simulator returned a clear error message ("Access Denied by firewall"). In Tier 3, when query_ca_templates was called from the wrong host, my simulator returned a bare {"status": "error"} with no message explaining why. Without an error message telling it that the command had to be run from CA01, the 8B model kept retrying the call until it ran out of steps.

Takeaways & Next Steps

Building this on a single RTX 3090 made two things obvious. First, stripping refusal vectors out of local weights is fast and keeps the model’s formatting intact, but it does not give the model any planning skill on its own. Second, small 8B models can learn to backtrack around network blocks if your synthetic training set includes failure-and-recovery paths, provided your tool wrappers return clear error messages when a command fails.

The biggest limitation of this experiment is that it ran against a lightweight Python state machine. My next step is to connect this training and evaluation loop to a full virtualized Active Directory lab (such as GOAD) with real tool outputs from Impacket, NetExec, and Certipy, and inject more multi-branch backtracking into the training trajectories so the model can handle longer chains without losing track of host state.

The Certified Red Team Operator (CRTO) is a fantastic certification for anyone looking to improve their internal netpen experience with some adversary simulation tools and techniques. The course is fairly self-contained and teaches all the exploitation and abuse methods needed to pass the exam. In addition to the course, you can also get subscription access to a well-built lab environment which gives you the opportunity to try out all the attacks taught in the course on live targets.

Why You Should Get It

A unique feature of the RTO labware is that a licensed copy of Cobalt Strike plus some awesome kits are provided to tinker and play around with. This really adds a dimension of realism since Cobalt Strike is usually only available to enterprises with deep pockets and those who know of a certain, le-funny site.

Furthermore, RTO ups the difficulty by just a bit from the usual HackTheBox/TryHackMe machines since the exam machines all have AV turned on which forces students to be cognizant of disk, memory, and behavior detections common on most Windows machines via Defender/AMSI. Students first learn all the tooling and techniques on machines with AV disabled, then, as practice for the exam, RTO encourages students to enable AV on the entire lab and re-practice everything to simulate the exam.

My biggest praise, however, for the RTO course is that there is an active community of students who are always available to help and answer questions about the course, lab, or exam. In fact, there was even a time when RastaMouse got on Discord to answer my questions on the weekend, and added a whole Ghidra module to the course because I was having trouble finding the byte sequences in my beacon payloads which were being flagged by AV.

My Journey

If you follow me on LinkedIn, you might have heard that I recently started my second summer internship in offensive security with IBM’s X-Force Red as a Penetration Testing intern. In my cohort was Dylan Tran, or as we knew him, Sloppy Gerald. Dylan is a malware developer, avid red teamer, and chicken broth enthusiast who is highly accomplished in the CPTC and CCDC competitions, even being named champion a couple of times (which is seriously no small feat). He encouraged me to try out the CRTO near the time when we completed a riveting netpen bootcamp taught by legends Shikata (James Rogers) and Choi, which covered Active Directory attacks (most of which I was already familiar with through previous HTB/THM experience) and Certificate Services (which was completely new to me).

The bootcamp left me captivated and hungry for more advanced AD exploitation. When I learned that RTO taught certificate services attacks, delegation attacks, malware evasion, and so much more, I signed up immediately. Over the next two weeks, I was completely occupied by the training, which I juggled with internship stuff like bootcamps, projects, and shadows.

Despite not eating, drinking, or sleeping on some days, I somehow managed to take notes, read through the entire courseware, and complete all the attacks on the lab in around 12-14 days, which was half the time I had originally planned to take. When I finished the course, my exam was about 15 days away, and thus, the excruciating wait began consisting of material review and anticipation, but mainly anticipation. Funnily enough, one day at work, Dylan strolled over to my desk and joked, “you should take it right now lol.” I looked at him like he was crazy and said, “what the hell, exam rescheduled!”

The Exam

That day at 6 pm, my exam began. I started by setting up my Cobalt Strike team server as a service so I wasted as few of the 48 hours provided to me on setup (which ended up being too much time anyway). Once everything was configured, I started my listeners and conducted the necessary modifications for my payloads not to be caught by Defender/AMSI.

After that, I opened an RDP session on the starting workstation (the exam is an assumed breach, so you get access to one low-priv machine) and executed my beacon. I did have to do some initial troubleshooting and privilege escalation, but soon enough, I was on my way. Initially, I thought I would be spending the whole night on the exam, and it was a Friday, so I thought an all-nighter wasn’t too big of an issue. But within 3 hours, I compromised the first domain and got 3 of the 6 flags needed to pass the exam.

At this point, it was 9 pm, and the office was getting kind of sketchy, so I hurried home, broke my fast, prayed the sunset prayer, downed a root beer, and got right back to it. Within the next 3 hours, I compromised the 2nd domain and submitted all 6 flags, which gave me enough to pass the exam and be granted the coveted CRTO badge.

Check out the beacon chain I had by the end! It was an insane 9-machine P2P beacon chain all relying on a single egress beacon. Needless to say, I was in a weird state being full of adrenaline due to my “house of cards,” but also annoyed since callbacks were snail-paced. I ended the day when I passed.

Aftermath

The next day, I attempted to get the 2 remaining flags but accidentally fell asleep without stopping the exam environment. When I woke up, I discovered that I had used up all my remaining time (lol, bummer). But a win is a win, and I took it gladly.

In my humble opinion, the exam was definitely challenging in that it required some savvy thinking and problem-solving, but it was certainly not difficult to the point of stress and anxiety (clears throat, OSCP). During my preparation, Dylan kept telling me to relax since I was always worried that the AV evasion would be too hard and I would fail because of it. But the exam really was doable and frankly quite enjoyable.

Bottom line, if you pay attention to the course material and are able to replicate all the attacks in the lab environment, you will ace the exam no problem. So if you’re on the edge, don’t sweat it and take a shot at this cert.

Future Plans

Overall, I felt that I needed a win in my security career since I got my first CVEs from last summer’s research at WithSecure, and CRTO was the perfect confidence booster to get me all fired up for offensive security again.

My post-CRTO plan was to immediately jump on CRTO II, which has been highly regarded as the perfect sequel into advanced red teaming (infrastructure stuff) and malware development (EDR evasion). However, we are currently in the middle of doing our internship research projects, so I don’t think I’ll be able to power through CRTO II with speed and dedication like I did with CRTO I since the second iteration of the course, as I’ve heard, is definitely NOT self-contained and requires extensive research and self-learning from external resources to be successful on the exam.

I think I’ll hop off the certification train for now and try to produce the most badass project I can for XFR and hope they like it enough to call me back with a full-time offer at the end of the internship!

The Mine Field was a challenge meant to assess a penetration tester’s scripting skills by presenting a 22x22 minefield and asking the tester to rapidly find the path from the starting point to the finishing point without hitting the bombs. Furthermore, in addition to the minefield expiring every seven seconds, the answer needed to be formatted as a sequence of directions such as D for down and L for left etc… while also being less than 500 characters.

As a quick summary, the way I solved this was by first scraping the webpage using Python. Then splitting the source code and formatting the minefield (which was inside an HTML table) as a two-dimensional array. After I had a navigable 2D array, I used the Breadth-First-Search (BFS) algorithm to find the path from the starting point to the finishing point and print what steps it took to get there. A more technical and in-depth writeup will follow below.

Step 1 – Transform the Minefield into a Python-Readable Format

The first part of this challenge was understanding how to get the minefield from the webpage into Python and making sure that at any point in time, the minefield displayed on the webpage and the minefield that Python was working to parse and solve were identical. Thankfully, the lab creators gave us a heads up about the minefield being connected to the session cookie of the browser.

I began by scraping the entire web page in its raw HTML form by importing the requests library and calling the get function to grab the web page’s source. I also passed my session cookies along with the URL so that I could retrieve the same minefield being shown in the browser. The code I used to scrape the web page is shown below.

It’s also important to note that the way I retrieved my session cookie was by opening my browser, right clicking, selecting the “Inspect” button, clicking on the “Application” tab, navigating to the “Cookies” section, and retrieving the .AspNetCore.Session cookie value.

Once I had a raw web request stored inside the raw_html variable, I wanted to parse the page’s source code into a sortable and searchable format while throwing out parts of the request I wouldn’t need (like the headers). I performed this by passing the web page’s text into a library called BeautifulSoup which parses HTML code and makes it easier to work with. This was done by importing the bs4 package and passing the raw_html variable to BeautifulSoup as shown and storing the output in the soup variable.

The next step was to figure out exactly which part of the web page contained the minefield I wanted to bring in. This involved viewing the web site’s source code and learning that the minefield was stored inside an HTML table. Each row of the minefield was enclosed in <tr> tags and each cell’s status (clear or rigged) was listed as an attribute of the further nested <td> tags.

To filter out all the extra code of the website, I used the find function of the soup object created in the last code snippet to extract only the HTML that was within the <table> tags. This was done as shown.

To refine this even further I wanted to divide this table into separate rows so that I could iterate over them and construct my two-dimensional array. I did this using some string manipulation with the split function which is available to every string object. I wrote the split function so that every time it comes across the </tr> tag (which signifies the end of the row), it creates a divider.

Now that I had everything in a digestible and clean format, it was time to build my 2D array. I initialized the maze variable as a global array and began the construction of a nested for-loop. The logic would be as follows. For every row in the minefield table, create an additional temporary array, split the row into individual cells (at the end of every <td> tag), then for every cell, check whether it had the keyword full, empty, start, or end. Based on the keyword, append to our temporary row, either 0, 1, or 2. Once iteration through every cell in a row is complete, and the length of our temporary array is greater than one, append the temporary array to our main maze array (making it an array of arrays or 2D). The code is shown here.

After coming this far, our output was looking pretty good. Execution of all the code discussed so far yielded the following results. When compared with the minefield displayed on the web page, everything was perfectly identical. Empty spaces were zeros, bombs were ones, and our goal was the number two.

Step 2 – Solve the Minefield

Now that we had our minefield in a 2D array, it came time to pick a pathfinding algorithm which would be used to search for the goal given a starting point and print the path taken to get there while avoiding the bombs. The algorithm I selected is the Breadth-First-Search (BFS) algorithm. It is explained well by Simplilearn. They say, “BFS is used to search a tree or graph data structure for a node that meets a set of criteria. It begins at the root of the tree or graph and investigates all nodes at the current depth level before moving on to nodes at the next depth level.”

Breadth-First-Search uses a queue data structure to store the node and mark it as “visited” until it marks all the neighboring vertices directly related to it. The queue operates on the First-In-First-Out (FIFO) principle, so the node’s neighbors will be viewed in the order in which it inserts them in the queue, starting with the node that was inserted first. Below is a diagram for some additional clarity.

Implementing this in Python to work with our minefield was quite a challenge, nevertheless, existing research was quite helpful in guiding the exercise. The first part of implementing BFS was to establish the key variables it would use. This includes the following:

• Creating a new maze and setting it to the one we retrieved from the website
• Establishing the minefield’s dimensions (rows x columns)
• Creating a double-ended queue (to hold the nodes we want to visit next)
• Adding our starting point to the queue (which will always be (0, 0))
• Defining possible directions that the algorithm could move in
• Assigning letters (L, R, U, D) to those directions by using a hash map
• Creating a blank Boolean array identical to the minefield to track visited locations
• Setting our starting point as visited (since we are already there)

The code to declare and set these variables is shown below.

Now that we have our variables ready, we can begin the processing of the minefield. This is done with a while-loop which will continue as long as there is something in our queue signifying that there are still coordinates left to explore. Each time the loop runs, we will pop out the next value from the front of the queue and look at all the moves we can make from that coordinate (up, down, left, right). We will send said move through a series of validity checks to determine if it’s out of bounds, if there is a bomb there, if we’ve already visited it, or if we’ve reached the goal. The logic can be understood better by reading the algorithm below.

Since there is a lot going on here, lets walk through it step by step. We start off with a while-loop which will continue to run as long as there are coordinates in the queue. Once the loop has determined that there is a coordinate in the queue, we will retrieve it, and check to make sure it is not the goal (which would make continuing the loop unnecessary). Once we know it’s not the coordinate we are looking for, we will send it to our for-loop. Our for-loop will try every move defined in our directions array which was declared earlier.

You might notice that the for-loop looks a bit odd. That is because we are not only looping through the moves in our directions array, but we are simultaneously keeping track of the index numbers of the moves we are trying so that we can look them up in our hash map and connect a given move to a letter (which we need for the answer format). We are using Python’s enumerate function to achieve this.

For every move the for-loop iterates through, it creates a new set of coordinates by adding the current coordinate to the coordinates of the relevant move declared in the directions array. This is performed in the new_row and new_col variables. Once a new coordinate is created, it is checked to determine whether it is out of bounds, if there is a bomb there, or if it has already been visited. If it gets caught in any of those checks, the move is abandoned and the next move is brought into the for-loop.

If the move manages to pass all the validity checks, the move along with its corresponding letter, is appended to the queue. The move’s coordinates are also marked as visited to prevent the loop from visiting places it has already explored or determined are dead ends. Once this runs for every single coordinate in the minefield, it will find the target and print all the directions and moves that were taken to reach it, giving a sequence of moves which we can submit as our answer. A demonstration is shown below.

The full script can be found at my GitHub.

Hey everyone, welcome back to my infosec blog! I am so very happy (and kinda relieved) to announce that I have finally passed the CompTIA Security+ SYO-501 exam with a score of 817/900 on my first try. Now, it may not be a big deal to most people, but I had some severe test anxiety before sitting for the Sec+ simply because I had read the experiences of several people on Reddit and other sites that had years of IT experience and still failed (some even a couple of times!)

In the end though, when I first saw that “CONGRATULATIONS!” screen, I almost lost it. I was so proud, relieved, and giddy with excitement because I saw the fruits of several months (3.5) of studying and prep before me. It’s quite embarrassing to admit but I (a 20-year-old college freshman), was skipping out of that testing building like a kindergartener.

If you’re new here and wondering why I dropped $250 (student pricing) on this cert in the first place, there are basically 3 main reason.

1. I wanted to prove to myself that I have the basic knowledge and dedication to learning in order to successfully enter and create a career in the field of cybersecurity (which is naturally ultra-competitive)
2. It’s a small (yet essential) step towards my ultimate goal of becoming a skilled penetration tester or red team operator.
3. It’ll give me a leg up on all the juniors and seniors competing for prestigious internships from consulting firms that are hiring in Houston like Protiviti, EY, Deloitte, RSM, etc…

Now, onto why I’m writing this post. In addition to venting my excitement and showboating just a little (hehe), I wanted to share some broad, high-level studying tips and tricks that I picked up from around the internet to help anyone who might be getting ready to take this cert before it expires on July 31st, 2021 which is right around the corner. Along with those, I’ll be including my test-taking strategies and the study plans I used to help me beat the time crunch (which is definitely real) and have the necessary knowledge to confidently answer the confusingly-worded questions on the test with ease.

I hope you find these helpful because I absolutely appreciated the wonderful people in the infosec community who posted very long reviews, experiences, study guides, plans, and strategies on their blogs and Reddit threads. I found them incredibly valuable and truly indispensable resources to prepare me for what was one of the most challenging exams I have taken to date. So, this is my way of giving a little back and sharing what helped me the most. Enjoy!

How I Studied

Now I am a full-time college student with a job and although I’m still a freshman, classes, work, and coursework can get a bit heavy at times. I needed a small window of opportunity to cover a large amount of the subject matter and familiarize myself with most of the vocabulary and concepts. Thankfully, the winter break of Fall 2020 was the perfect opportunity as apparently in college, it lasts a whole month.

I used the winter break to study Darrell Gibson’s study guide book which I bought discounted on eBay for $20. I read a chapter every day and did the coinciding quizzes on the back of each chapter getting consistent 80s & 90s. Once I finished the book in 11 days and aced the readiness assessment at the end of the book, I felt like I was ready for the exam. That’s right about the time when Reddit shattered my confidence and I ended up rescheduling my exam.

The majority of warnings/ red flags I gathered from peoples failures consisted of the following

• You shouldn’t study from a single source only
• Performance-based questions exist (and they’re hard)
• Overconfidence backfires
• Time crunch is 100% real
• Memorization will get you nowhere
• Practice tests are useless compared to the actual questions
• etc…

Suffice it to say, I was worried and had to go back to the drawing board because I felt like I was taking it too easy. I started by dividing my studying into 3 phases. Phase 1 was familiarity and high-level understanding. Phase 2 was a detailed study and key concept reviews to fill in knowledge gaps. Phase 3 was practice tests, flashcards, and PBQ prep. Here’s how I implemented each phase.

Phase 1: Material Familiarity

I started this phase by rereading and reviewing Darrel Gibson’s entire study guide all over again. I also redid the quizzes which I mostly scored perfectly on the second time around. Once I had grasped mostly all his material, I went ahead and moved to the next phase.

Phase 2: Gap Filling

This phase was mostly to address the diversity of learning resources which was a major factor in my exam score. I only figured out how much I didn’t know once I started dabbling in other people’s video courses and prep material.

• I started out with the well-known (and free) Professor Messer Training Course and completed one playthrough of his Security+ playlist while at work, driving, etc…
• Then I moved to Mike Meyer’s Total Security+ Video Course on Udemy which is around $15 (but I got it free)
• Finally, I ended with Mike Chapple’s Become a CompTIA Security+ Certified Security Professional learning path on LinkedIn Learning which is also free for me because I work at my university

The shocking thing for me was that each of these resources covered a lot of overlapping material but every so often, I would come across something that was not in the other materials which really made me grateful that I postponed my exam and looked for other things to study from. Once I was confident that I knew all the concepts that I would need for the test, I moved on to the next phase to apply what I had learned and test the breadth of my understanding.

Phase 3: Practice, Practice, Practice!

The best and most accurate practice test and prep platform I used was the GCGA SYO-501 Full Study Package which is by Darrel Gibson (who wrote the study guide I read). It costs a cool $65 but I got it discounted for Christmas at $50. It came with hundreds of practice test questions which were actually challenging, 4 sets of accurate PBQs, several other mini-quizzes, and flashcards for acronyms and important tidbits to help reinforce your understanding and gauge your readiness. Here is where I really understood how much more I needed to practice before sitting for the actual test. I bombed most of them in the beginning but slowly began to improve my scores after re-studying the concepts I missed.

Unfortunately, though, my membership expired before I felt ready enough so I found another website with THOUSANDS of practice test questions and 12 PBQ sets. This one is really difficult to explain because most of the question sets are fantastic, but some sets have bogus answers with no explanations so I wouldn’t recommend it as a primary resource. It’s still nice to have but only if you’ve aced Darrel Gibson’s practice questions.

The final resource I used to practice was Quizlet. I never thought I’d use that for this but it was surprisingly helpful. Although there were flashcards in the GCGA package, these were still a great refresher for what I had forgotten or what slipped my memory.

• Important Terminology
• Acronyms (must know and understand in-depth)
• Port #s (not as important as people say but still must know)

Days Before The Exam

After all my prep, I truly felt ready and was confident that I could certainly pass the exam if it came down to it. I pushed up my test and left a couple of days for rest and to read up on some awesome test-taking strategies. Some of the ones that I found most useful were the following.

• Arrive early and make sure you bring your ID and Credit/Debit card
• Use the bathroom BEFORE sitting for the test
• Skip the 5 or so PBQs at the start and flag them for review (DO THEM AT THE END)
• Keep track of your time (It’ll creep up on you)
• Be well rested and in peak mental state
• Eat something light before taking the test
• Use the process of elimination for ones that you’re unsure about
• Don’t be cocky, think, and read the question twice if you must

If you can manage to do some or most of those things, you’ll be absolutely fine on the exam. Another critical last-minute prep that I did was to review the CompTIA objectives sheet and research or lookup any concept, tool, or technology that I wasn’t 100% sure of. There is also a list of acronyms in the objectives which have some weird additions that I didn’t find in the flashcard, so taking a look at that would be a huge plus.

But that’s about it. In summary, the exam is tough but it’s not impossible. If you study the objectives, diversify your resources, and keep a cool head during the test, I’m certain you’ll be able to get a great score and a solid cert under your belt.

If you have any questions, feel free to reach out to me on my LinkedIn!

First of all, welcome to my infosec blog! If you don’t already know, my name is Abdullah Ansari and I’m currently a freshman in college attending a public university in Houston. Some of my interests (other than infosec) are playing open-world games, real estate investing, learning languages, and hanging out with family and friends. You can say I’m pretty much your average college kid.

Ever since high school, I’ve been fascinated by the world of “hacking” which advertises itself as an adrenaline-filled life of breaking into systems, networks, and buildings you aren’t supposed to be in. I didn’t hack my school and change everyone’s grades or anything spectacular (& stupid) like that, but I’ve allegedly done my fair share of script kiddie stuff on my PRIVATE labs of course.

My real hook into this field though was a youtube video by Insider which showed an actual red team in action. Basically, a cameraman followed the team around as they stealthily infiltrated and compromised several critical power stations and control centers in the local power grid. Seeing the tools they used and the absolute blast they were having while picking locks, flying drones, and fooling sensors really made this a serious deal for me.

I felt like it clicked and figured that a career like this would be a dream. Ever since then, I’ve been having tons of fun playing around with GitHub scripts, Metasploit, Kali boxes, and lock picks while dipping my toes into some theory and basic IT fundamentals.

Why cybersecurity?

Now, at some point after high school, I began to think about what I wanted to do with my life career-wise. Since I chose to be an MIS major (which is under business), I had several options. I could choose from management consulting, IT consulting, project management, data analysis, software engineering, business analysis, etc..etc… Unfortunately, with all due respect, all of these seemed extremely tedious and boring to be completely frank. I hated coding with a passion (thanks to AP CompSci 1&2) and organizational management talk put me to sleep real quick.

After taking my first semester, I finally realized that I could do what I love and enjoy doing and have someone pay me a ton of money and give me a job with great benefits, high flexibility (partly thanks to covid), and job security which seems like a SWEET deal if you ask me. So now, I have decided to pursue this path with the dedication and tenacity of someone who REALLY wants to be successful in this field. If I’m able to pull this off, I can sincerely and honestly say, that I will absolutely not be from among the 85% of Americans who hate their job.

Why this blog?

Onto the good stuff. After hanging around and interacting with the security community on forums, Linkedin, and other blogs, I’ve learned that this group places an enormous value on giving back and helping out whoever you can with whatever you have expertise in. This is actually one of the things that drew me further into this field.

For example, I’m currently studying for the CompTIA Security + exam and I can’t even count how many “my experience” or “my journey” posts I have read over the internet. Needless to say, they have all been incredibly helpful with links to materials, proven strategies, and tips/tricks that only come by actually doing things.

All of this free information and selfless passing down of knowledge has inspired me to create a blog myself to hopefully give back a fraction of what I have taken from the InfoSec community. Even helping a single person would be enough to satisfy me, but my aim is to reach as many people and provide as much value as possible.

For the duration of this blog, I will closely monitor and journal every major step in my journey to turn my passion into a full-time career. I will talk about everything from college to certifications to interviews and everything in between, so stay tuned if you’re interested.

Goals

Now, as of this moment, I have no shame in saying that my hacking skills are just a bit above the script kiddie level. However, I realize that I’ve got a long way to go and that actually makes me really excited. My uncle once told me to just enjoy the journey and stop worrying about the destination, it will come by itself, and I plan on taking his advice (you should too).

A general roadmap for me right now, based on everything I’ve read and researched looks pretty straightforward.

1. Throughout the next few years, I will be doing a healthy mix of courses from Udemy, PluralSight, and SANS to build up core skills and methodologies.
2. To practice my said skills, I will use HackTheBox machines, VulnHub machines, and the highly praised Virtual Hacking Labs machines.
3. Finally, I will attempt to complete several well-known, entry-level certifications like the Security +, eJPT, eCPPT, CRTP, and the OSCP to prove my skills to employers.

So that’s the plan ladies and gentlemen. That being said, things are quite shaky in the world right now what with covid and all, so things might shift here and there, but I’m set on getting through this and making something out of myself. Plus, I’ll get to share my experiences, learn from the community, and also give back what little I can, so I see it as a win-win-win. Anyways, this is probably the longest post I’ll ever write, but now that formalities are out of the way, I’ll embark on this path with the next post which will document my Security + journey so be on the lookout for that. See ya’ll on the next one!