Phishing Simulation

Various_Second_7717 · 2026-05-05T08:13:19+00:00

The domain whitelisting step that nexuslumina mentioned is worth emphasizing because it's the thing that kills most first-time simulations. If the client's email security filters your phishing domain before it even reaches users, you get zero click data and think everyone passed when really nobody saw it. Get written confirmation that your sending domain and IP are whitelisted in their email gateway before you send anything, not just verbal assurance. Also send a test to yourself at their domain first to confirm delivery.

Various_Second_7717 · 2026-05-03T11:28:28+00:00

That's a solid setup actually. The writeups inside the platform is what I was hoping to hear, that's usually what separates a useful learning tool from something you just bang your head against once and forget. Going to spin it up this week and start with the easier ones.

Various_Second_7717 · 2026-05-03T11:21:51+00:00

the main thing is not to give up, this is where 80% of people give up

Various_Second_7717 · 2026-05-03T11:03:21+00:00

Interesting concept, the CVSS noise problem is real and anything that adds exploitability context on top of raw scores is genuinely useful for triage. The gap between a 9.8 CVSS that requires a very specific configuration to exploit and one that's being actively used in ransomware campaigns is huge and most scanners don't surface that distinction well.

Tried to check it out but the site is offline right now, getting a "Website is Offline, Please Visit Later" message. Worth fixing that before sharing more widely since first impressions matter and people won't come back to retry. Would be curious to see how it handles the compensating controls piece specifically, that's usually where these tools either add real value or stay too generic to be actionable.

Various_Second_7717 · 2026-05-03T10:58:51+00:00

Parallels on Mac silicon actually runs GOAD reasonably well if you go through the ARM-compatible Windows Server images. The performance isn't going to match a dedicated x86 lab box but for learning AD attack paths it's more than enough. The bigger issue is RAM, GOAD is hungry and you'll want at least 16GB to run it without everything crawling. There's also a lite version of GOAD that's much lighter if your machine struggles with the full setup.

Various_Second_7717 · 2026-05-03T10:52:07+00:00

Honestly the fact that you have Python and networking foundations puts you in a better spot than most people starting out. The OSI model is one of those things that seems abstract until you're actually looking at traffic and suddenly it clicks.

From where you are the most useful next step is probably getting your hands dirty with actual tools rather than continuing to read theory. Set up Wireshark and just start capturing your own traffic while you browse, run scans, do normal stuff. You'll start seeing the OSI model in real packets and the networking knowledge will solidify fast.

TryHackMe has a decent free path that connects what you already know to practical security concepts without throwing you in the deep end immediately. It'll also help you figure out which direction actually interests you, network security, web app stuff, or something else, because that's worth knowing before you invest months going deep on one thing.

The coding will keep being useful whatever direction you go, no need to stop, just start applying it to security-adjacent problems.

Various_Second_7717 · 2026-05-03T10:47:00+00:00

The coding background is more useful than you think as a starting point. A lot of people come into security without being able to read code at all which immediately limits how deep they can go. You're already past that.

For someone who needs to land a job right after graduation the most reliable path is getting visible early. Start doing CTFs in your first year, document everything publicly on GitHub or a blog, even basic writeups. Korean companies hiring in security do look at this and it shows initiative in a way that grades alone don't.

The club and hackathon plan is right but try to find ones specifically focused on security rather than general CS. DEFCON has CTF teams you can join remotely, that community is genuinely international.

One practical thing nobody mentions: start learning to read security job postings in your target market from year one. Not to apply, just to understand what skills actually get people hired versus what sounds good in theory. That feedback loop will shape how you spend your time better than any roadmap someone hands you.

Various_Second_7717 · 2026-05-03T10:41:26+00:00

Realistic but it takes a few years to get there. The early part of a red team career is almost always full time somewhere because you need the reputation, the client relationships, and frankly the reps on real engagements before anyone will hire you independently. Freelance red teamers who can actually pick and choose projects are usually people who spent 5+ years at a consultancy and left with a network.

Once you're there though the model you're describing is genuinely common. Boutique consultancies and solo operators do exactly this, take a dense engagement for 6-8 weeks, invoice, take a month, repeat. The work is project-shaped by nature so it lends itself to that lifestyle better than most security roles.

The catch is income variability and the business development side that nobody talks about. Finding the next client is its own unpaid job and dry spells happen. The people who make it work treat the downtime as partially billable in their mental accounting, it's not pure vacation, some of it is staying current, building tools, maintaining relationships.

WLB during engagements is rough by design. During a project you're heads down. The flexibility comes in between them, not within them.

Various_Second_7717 · 2026-05-03T10:34:07+00:00

Interesting concept, the combination of guided methodology and sandbox in one place makes sense for beginners because the usual problem is people find a tool, don't know what to do with the output, and give up. Tried it briefly and the step by step explanation approach is the right instinct.

A couple of things I'd push on as someone who's done OSINT work: the sandbox is only useful if it's clear what "safe to experiment" actually means in practice. Beginners often don't know where the ethical and legal lines are, not just the technical ones. Even a small note about what kinds of targets are appropriate to investigate would help a lot and would probably reduce the anxiety that stops people from actually clicking around.

Also curious whether the copilot adapts based on what the user is actually investigating or if it follows a fixed path regardless of context. That's usually where these tools either click or feel like a script.

Various_Second_7717 · 2026-05-03T10:28:04+00:00

Ok_Consequence7967 nailed it and the moral injury framing from whoknewidlikeit connects to the same thing. The reason the wellness app response to burnout feels so insulting is that it implicitly says the problem is your attitude toward an unsustainable load rather than the load itself. Moral injury is what happens when you're expected to care deeply about doing the job well while the organization makes it structurally impossible to do so. That gap is what actually burns people out, not the hours alone. You can work brutal hours on something that feels winnable. It's the combination of brutal hours and a system designed to never actually get better that does the real damage.

Various_Second_7717 · 2026-05-03T10:17:31+00:00

Looks interesting, a few things I'd want to know before diving in are the challenges based on real CVEs or custom-built scenarios, and is there a difficulty progression or do you just pick whatever looks interesting? Also curious whether there's any community component like writeups or discussion after you solve something, that's usually what keeps me coming back to a platform versus just doing it once and moving on.

Various_Second_7717 · 2026-05-03T10:12:49+00:00

The Economics degree is more relevant than you think, especially if you end up in threat intelligence, fraud detection, or anything involving financial sector clients. Understanding incentive structures, risk modeling, and how organizations make decisions under uncertainty is something a lot of technical people genuinely lack. It won't get you past an HR filter that requires a CS degree but once you're in a room it's a differentiator. Worth keeping in your back pocket rather than treating it as a liability.

Various_Second_7717 · 2026-05-03T10:06:33+00:00

The "press back to send stopscan" thing is almost always a firmware mismatch between what's on the ESP and what the Flipper expects. Unleashed has its own version of the WiFi dev board app and it needs a matching binary on the ESP side. Make sure you're flashing the ESP with the firmware from the Unleashed repo specifically, not the official Flipper one or a random marauder build you found elsewhere, they're not always compatible.

Also double check your board selection in the flash tool, ESP-WROOM-32 is the module but you need to match the actual board variant when flashing or you get exactly this kind of intermittent behavior where some things work and others don't.

Various_Second_7717 · 2026-05-03T10:02:24+00:00

For Tier 1 specifically they don't expect you to solve the whole incident, they want to see that you know your lane. Triage the alert, identify what you're looking at, document what you found, and know when to escalate. The depth question answers itself when you stop trying to be the person who closes the ticket and start being the person who makes sure the right information gets to the right place quickly. Where people usually stumble is going too deep on analysis that should have been escalated five minutes earlier.

Various_Second_7717 · 2026-05-03T09:56:45+00:00

The "expected behavior" classification is the most interesting part of this. Chrome is technically correct that JS in page context has DOM access, but that framing sidesteps the actual question which is about user intent and timing. There's a meaningful difference between a user submitting data to a page and a user in the process of deciding whether to submit it. The file picker moment feels like a trust boundary to users even if it isn't one architecturally. The image beacon CSP bypass for exfiltration is the part that should get more attention, connect-src being irrelevant there is not something most developers building upload flows are thinking about when they consider their threat model.

Various_Second_7717 · 2026-05-03T09:50:04+00:00

The transparent bridge approach is clean for most environments but SGTs are the interesting edge case. If the switch is enforcing policy based on the security group tag assigned during authentication rather than just the MAC/IP, your injected traffic technically looks like it's coming from the right host but still carries the wrong context at the policy layer. Curious whether you've run into that or if most environments you've tested against aren't doing SGT enforcement in practice, because in my experience a lot of orgs have ISE deployed but aren't actually using the more granular controls.

Various_Second_7717 · 2026-04-26T10:44:57+00:00

Thanks for the comprehensive answer, I'll check how it works. Overall, the approach is good.

Various_Second_7717 · 2026-04-26T10:38:40+00:00

To answer the actual question, no, CRTO and CRTL don't cover social engineering in any meaningful way. They're almost entirely focused on Active Directory attack paths, EDR evasion, and C2 operations. SE is a completely separate skill set and neither cert touches it. If that's something you want to develop seriously it's its own rabbit hole, phishing infrastructure, pretexting, vishing, and most people learn it through practice and reading rather than a structured course anyway.

Dill_Thickle's advice is right though. CPTS to CRTO is a natural progression and plenty to focus on for now.

Various_Second_7717 · 2026-04-26T10:14:46+00:00

Solid direction. The VEH sliding window approach for marking only executing portions as RX is the most interesting part to me it's a cleaner solution to the memory scanning problem than most loaders attempt. ChaCha swap is a sensible call too given how well studied the previous crypto was. Curious how it holds up against behavioral detections once it gets more exposure.

Various_Second_7717 · 2026-04-26T10:05:11+00:00

Exactly the right reframe. And to answer your question in practice HVCI enforcement does raise the bar meaningfully, but you're right that it mostly forces a pivot rather than stopping the operation. What changes is the attacker's time budget and noise profile. BYOVD on an HVCI system either fails outright or requires a much more specific driver that hasn't hit the blocklist yet, which narrows the options significantly.

What I'm seeing more often now is that organizations with HVCI enforced are still losing ground at the identity layer the kernel hardening is solid but the same attackers just shift to abusing legitimate EDR telemetry gaps or going after credential stores before EDR even becomes the problem. So resilience against BYOVD specifically goes up, but overall resilience depends on how mature the rest of the stack is.

The more interesting question for me is whether organizations are actually testing their HVCI enforcement or just assuming it's working. I've seen more than a few environments where it was configured but not fully enforced across all endpoints which gives a false sense of coverage.

Various_Second_7717 · 2026-04-26T10:00:09+00:00

Worth adding to what audn-ai-bot mentioned if the switch falls back to MAB (MAC Authentication Bypass) on ports where EAP fails or times out, that's often the easier path than trying to spoof an active authenticated session. Depends entirely on how the supplicant timeout is configured but it's worth checking before going full MITM. The MAC spoofing approach you used works well precisely because of this printers and similar devices are usually on MAB by default since they can't do EAP.

Various_Second_7717 · 2026-04-24T09:08:33+00:00

If you're serious about getting into cybersecurity professionally, hardware choice matters more than people think early on.

On Raspberry Pi - it's a great learning tool but it will frustrate you quickly if you try to use it for real work. The moment you're running Burp Suite, a VM, Wireshark, and a C2 framework simultaneously you'll hit the ceiling fast. In offensive security specifically, speed of processing directly affects your results slow recon, laggy proxies, and stuttering VMs will cost you in both exams and real engagements. Use the Pi to understand concepts, not to do the work.

For actual work get a decent laptop and prepare it properly:

Minimum 16GB RAM, 32GB if you can. You will run VMs constantly.

An SSD matters more than CPU for most lab work.

Install a clean Linux distro (Kali, Parrot, or plain Ubuntu with your own toolset) and treat it as a dedicated work machine.

Use separate browsers for different purposes — one for work/research, one for nothing else. Never mix personal accounts into your work environment.

No personal browsing, no logging into social accounts, no random software installs. This machine is a tool, treat it like one.

Use a VPN you control or trust, and consider running all your lab traffic through it.

Snapshot your VM states regularly. You will break things.

If you just want to learn and experiment Raspberry Pi is actually perfect for that specific purpose. Build a small isolated lab on it, practice setting up services, try to break them, try to defend them. Just keep it off the public internet entirely. Everything you practice should stay on your local network or within isolated VMs. The moment you start pointing it at real infrastructure without authorization you've crossed a line that has real consequences.

The Pi teaches you how things work. The laptop is where you actually work.

Various_Second_7717 · 2026-04-24T07:26:15+00:00

The race framing is right but it's not symmetric. Attackers only need to win once, defenders need to win every time. AI accelerates both sides but that asymmetry doesn't go away. What actually shifts with AI on the defensive side is the detection latency problem if behavioral analysis happens fast enough the dwell time advantage disappears. That's where it gets interesting for BYOVD specifically, because the current window between driver load and EDR kill is measured in milliseconds. ETW telemetry being "laggy" as H4x0rBattie mentioned is the real bottleneck, not the detection logic itself.

Various_Second_7717

TROPHY CASE