This page serves the raw LLM context file. You can access the raw text file directly at /llms-full.txt.

# Jorel's Blog — Complete Site Context
# Generated dynamically. All published posts and pages.
# Total articles: 8
# Last updated: 2026-07-05T11:23:22.784Z

---
# TITLE: About
## Type: Page

Hey, I'm Jorel.

I work as a CISO, which is a busy enough day job on its own. Outside of work, I do a lot of free mentoring, informal consulting, advisory work, and I sometimes post my thoughts on LinkedIn. But LinkedIn has its own set of issues, so I wanted a parallel home for my content where I have total control over the functionality.

This space is entirely free and I am holding firm on that. There are zero ads and zero tracking scripts. Since I'm not collecting a single piece of your data, you won't see an annoying cookie banner here. If you ever happen to spot a weird tracker hiding on this domain, let me know so I can kill it.

Eventually, the goal is to build out some open features so people can grab these notes however they prefer, whether you use an old-school RSS reader, just want a clean webpage, or want to pull raw markdown into an AI window.

The site itself isn't fully there yet, but I'm working on it. Bear with me while I attempt to get the plumbing sorted out.

The best way to get in touch is to connect with me on [LinkedIn](https://linkedin.com/in/jorelv) or email me at jorelv [at] gmail [dot] com.
---
# TITLE: Securing Entra Tier 0 Roles
## Date: 2026-03-17
## Excerpt: Phishing-resistant MFA for Entra ID admins is a great start, but it won’t stop attackers from downgrading flows, stealing session tokens, or registering rogue devices. Securing Tier 0 identity perimeters requires a hardened Conditional Access Policy (CAP) architecture. Here is how to close some of those gaps.

Phishing-Resistant MFA for your Entra ID admins is the right move. But if that is the _only_ control you configure, you are leaving multiple bypasses wide open.

Attackers do not need to break your FIDO2 key. They will just downgrade the authentication flow, steal a session token, or register their own MFA method to establish persistence.

Securing privileged identities requires a comprehensive Conditional Access Policy (CAP) architecture to close these gaps.

## Scoping the Tier 0 Perimeter

Before building these policies, you need to know exactly which accounts belong in this scope. I recommend using the [SpecterOps Tier Zero table ](https://specterops.github.io/TierZeroTable/)as your guide.

For all the policies below, the baseline scope is to target your **Tier 0 user groups** and apply them to **All Cloud Apps**.

## Core Conditional Access Policies

### 1. Enforce Phishing-Resistant MFA

- **Grant:** Require Authentication strength → Custom Authentication Strength (Phishing-resistant methods + Temporary Access Pass).
- **Architectural Note:** You must build a custom strength to allow TAPs for initial onboarding or recovery, as the built-in phishing-resistant strength does not include it.

### 2. Secure the Security Information Portal

Attackers will attempt an MFA downgrade attack to bypass your primary controls. If successful, their immediate next step is registering their own phishing-resistant MFA method to cement their access. This policy breaks that chain.

- **User Actions:** Register security information (instead of all cloud apps).
- **Grant:** Require Authentication strength → Custom Authentication Strength (Phishing-resistant methods + Temporary Access Pass).
- **Session:** Set **Sign-in frequency** to Every time.

> **Note:** Forcing "Every time" on the security registration portal triggers a fresh, mandatory MFA challenge even if an attacker attempts to access the portal using a hijacked session cookie.

### 3. Enforce Device Compliance & Block Unsupported Platforms

Privileged Access Workstations (PAWs) are the standard, but at a minimum, you must require a compliant device and explicitly block everything else. If you only target Windows/macOS for compliance, an attacker can bypass the check entirely by spoofing a Linux user agent. You need two distinct CAPs here:

**CAP A (Require Compliance & Entra-Joined)**

- **Conditions:** Device platforms → Include Windows and macOS.
- **Grant:** Require device to be marked as compliant **AND** Require Entra-Joined device.
- **Compliance Note:** Your Intune compliance policy should require an active EDR sensor running on the local machine.

C**ACAPP B (Block Unsupported**)

- **Conditions:** Device platforms → Include Any device, _Exclude_ Windows and macOS.
- **Grant:** Block access.

### 4. Block Vulnerable Authentication Flows

Phishing-resistant MFA means nothing if an attacker can bypass it using legacy or alternative protocols.

- **Conditions:** Authentication flows → Select Device code flow and Authentication transfer.
- **Grant:** Block access.

### 5. Session Controls to Mitigate Token Theft

While a properly tuned EDR should detect and kill the infostealers attempting to scrape session cookies, you need an identity-layer fallback for when the endpoint control fails.

- **Session:** Set **Sign-in frequency** to a short duration (e.g., 1-4 hours) and completely **disable persistent browser sessions**.
- **Note on Sign-in Frequency (SIF):** Since these are dedicated admin accounts, we do not care about breaking Outlook or Teams background sync. However, setting this to "Every time" against _All Cloud Apps_ will break Azure CLI, PowerShell scripts, and background portal telemetry. Use a short hard duration here, and reserve "Every time" strictly for high-risk targets like the Security Info portal above.

### 6. Enforce Token Protection

Token Protection cryptographically binds the session token to the specific device so it cannot be replayed on an attacker's machine.

- **Session:** Require token protection for sign-in sessions.
- **The Caveat:** This primarily protects native thick clients and specific Microsoft Edge configurations linked to the Primary Refresh Token (PRT). It leaves standard browser web sessions (like Chrome or Firefox) exposed. Because your admins operate heavily in web portals, aggressive Sign-in Frequency (the policy above) remains your primary defense for web sessions.

## Tenant Hardening & Administrative Controls

Beyond your CAPs, you must harden your core tenant configuration against social engineering and administrative bypasses:

### Protect the Architecture & Stop Helpdesk Phishing

Place your target admin groups inside a **Restricted Management Administrative Unit (AU)** and use **Role-assignable groups**. This prevents standard administrators or compromised helpdesk accounts from modifying your CAP configurations, changing group memberships, resetting passwords, changing MFA methods, or generating TAPs for Tier 0 accounts.

### Custom MFA Alerts

Microsoft does not have a native feature to send an email when a new MFA method is added. You should build a custom **Logic App** to monitor the audit logs and alert users/admins immediately when new methods are registered.

### Disable Self-Service Password Reset (SSPR)

We are not trusting passwords, so we do not need resets. Disable this at the user level and restrict built-in administrator password reset policies.

## Operational Governance

### Monitor for Configuration Drift

CAPs are only as good as they are on day one. Over time, exceptions are made, and policies drift from your intended secure state.

- **Tooling:** Use open-source frameworks like **Maester** or automated GitHub/GitLab scripts to continuously validate your tenant against your baseline.
- **Native Alternative:** Leverage Microsoft's new **Unified Tenant Configuration Management (UTCM)** APIs to capture snapshots and automatically monitor for configuration drift natively via Microsoft Graph.

### Restrict Device Enrollment

Limit who can join or register devices to Entra ID to prevent an attacker from enrolling a rogue virtual machine to bypass your device compliance rules.

### Configure Break-Glass Accounts

Exclude at least two highly monitored, cloud-only emergency access accounts from these CAPs to prevent tenant lockout during a Conditional Access misconfiguration. Secure them with physical **FIDO2 Security Keys**, which continue to function seamlessly even during a total Microsoft MFA (telephony/push) service outage.

### Strict Identity Separation

Strictly separate admin and user accounts. Keep admin accounts cloud-only and never sync them from on-premises directories.

### Just-In-Time Escalation

Use **Privileged Identity Management (PIM)** for just-in-time access, enforcing active justification and strict activation time limits.

_What else are you seeing get missed out in the wild? Let's talk in the comments below._

---
# TITLE: The False Security of Browser Password Managers
## Date: 2026-03-09
## Excerpt: Built-in browser password managers solve the basic password reuse problem, but they fail completely in the face of modern endpoint compromise and infostealer malware.

This headline reads like it was sponsored by Lumma, Redline, and Raccoon Stealer.

The author's intent is clearly good. Getting users to adopt built-in tools is vastly better than watching them reuse the same weak password across fifty sites. Moving the needle on basic hygiene matters.

But the practical outcome of this advice is a gift to commodity malware operators. Advising people to ditch dedicated password managers ignores how modern credential theft actually works. Browsers are the primary target for infostealers, and relying on them for credential storage introduces a fundamental architectural risk.

## Why Built-In Managers Fail the Endpoint Compromise Threat Model

Here is why built-in OS and browser managers are not a replacement for a dedicated vault:

• **The Execution Context Problem**: Browsers natively rely on the OS to handle encryption (like DPAPI on Windows). If a user executes an infostealer payload, that malware runs in the user's context. It simply asks the OS to decrypt the local SQLite database, and the OS complies.

• **The Failure of App-Bound Encryption**: Google recently tried to fix this in Chrome by introducing App-Bound Encryption, binding the decryption key to the Chrome application identity. It took infostealer developers less than two months to bypass it using COM hijacking and remote debugging exploitation.

• **The Independent Encryption Boundary**: Dedicated vaults maintain their own encryption boundary. The vault on disk is encrypted using a key derived from a master password. Is this foolproof? No. An active keylogger or memory scraper can still dump an unlocked vault from RAM. But the vast majority of commodity stealer logs are generated via smash-and-grab SQLite extraction. Moving credentials to an independent vault forces attackers to use active monitoring, drastically raising their required effort.

Built-in tools solve the password reuse problem, but they fail the endpoint compromise threat model. We need to stop telling the public that foundational security tools are obsolete just because OS vendors bundled a basic alternative.

---
# TITLE: The Entropy Illusion: LLMs and Passwords
## Date: 2026-03-03
## Excerpt: The Entropy Illusion: LLMs and Passwords

Because of how LLMs are engineered, raw randomness is actually against their core architecture. Here's why AI-generated passwords fail basic entropy tests, the "looks secure" trap of tokenization bias, and how you can use a sandbox workaround to force an LLM to delegate true, mathematically sound entropy.

The baseline rule: Use them to write the code, not the password.

The Register recently confirmed what most of us already knew: LLMs are terrible at generating secure passwords. Researchers found that major models consistently fail basic 16-character entropy tests.

Instead of rehashing how they fail, I ran an experiment to see if I could force one to succeed anyway.

The reality is you can use an LLM to get a mathematically secure passphrase. **You just have to stop asking it for the string directly.**

### Why LLMs Fail at Raw Randomness

We know that asking an LLM to simply output a random password fails due to its base architecture:

- **Tokenization bias:** Models do not generate characters. They pull from a token vocabulary based on what their training data suggests a "strong password" looks like.
- **Predictive optimization:** LLMs are prediction engines built to minimize chaos. Asking them for raw entropy is asking them to work against their core function.
- **Human expectation:** Models generate outputs that "look" secure to humans (like substituting vowels for numbers) but are highly predictable to an offline cracking rig running Hashcat.

**The "Looks Strong" Trap**

During recent research, a generated string like G7$kL9#mQ2&xP4!w was tested. While standard strength tools like zxcvbn estimate it would take "centuries" to crack based on simple length and character-class heuristics, its tokenized origin dramatically narrows the real search space for offline brute-forcing tools.

### Delegating the Entropy

To actually get a secure passphrase from an LLM, you have to force it to delegate the entropy. I gave a model a simple prompt: _write a script using the EFF Large Wordlist to generate a 4-word passphrase (mirroring the useapassphrase default)._ I didn't specify the language or the library.

The model chose Python and the OS-level secrets module (a true CSPRNG). Then, it pushed back. It pointed out that 4 words only yield \approx 51 bits of entropy and practically begged me to let it use 6 words to hit a mathematically secure 77.5-bit threshold. I let it run the 6-word version.

The result was mathematically sound because the OS provided the randomness, not the LLM's softmax distribution.

The script even generated consecutive duplicate words ("slushy slushy"). This is a classic Birthday Paradox artifact. While it doesn't definitively prove true randomness, it is solid evidence that the generator didn't fall into the human-bias trap of artificially preventing repetition. That "random-looking" bias actually weakens the keyspace.

### The Sandbox Precedent

We have already seen how AI providers solve this kind of architectural flaw. If you ask a modern LLM to do complex math, it doesn't try to predict the next token. It silently writes a Python script, executes it in a sandbox, and feeds the output back to you.

My prediction is that it is only a matter of time before models treat "give me a password" the exact same way. System prompts will detect the request and route it to a script exactly like this one, returning true OS-level entropy instead of a token hallucination.

But even when they do, the baseline rule remains: **you shouldn't trust an LLM to generate your secure passwords or secrets.** People will undoubtedly continue to ask for them anyway, but the right approach hasn't changed.

> **Use them to write the code (and human-validate it), not the password**

---
# TITLE: The Pirate Author and the AI Coworker: Hugh Howey's Frictionless Future
## Date: 2026-02-11
## Excerpt: Years before ChatGPT, sci-fi author Hugh Howey (Silo/Wool) predicted the rise of the AI coworker, welcoming it as a creative augment rather than a threat. By embracing piracy and pricing for accessibility, Howey proved that friction is the true enemy of progress. Here is what technologists can learn from a writer who valued output over process.

One of the best AI predictions didn’t come from a technologist. It came from an author who welcomed piracy.

Years before ChatGPT, sci-fi author **Hugh Howey** (_Silo_/_Wool_) predicted an AI coworker. But he didn't write this in his novels; he wrote it in a blog post about his own future.

He wasn't world-building. He was planning.

He foresaw a time where he wouldn't be replaced, but augmented. He envisioned writer and machine iterating together. This perspective resonates because it rejects the binary fear/hype cycle we see in cybersecurity and tech today.

He wasn’t trying to protect the "old way" or maintain a monopoly on creativity. He was obsessed with the output, not the ego of the process.

## Defending the Output, Not the Process

Instead of wasting energy defending the status quo, Howey focused on removing friction:

- **He didn't fight piracy; he leveraged it.** He famously placed a "Pro-Piracy" button directly on his site, understanding that obscurity was a far bigger risk to a creator than theft.
- **He priced for accessibility, not strategy.** He sold his work for $0.99 when that price point was considered crazy by the publishing establishment. It wasn't a calculated "pricing tier" but simply the lowest price Amazon allowed. He viewed writing as a passion to be shared, not a product to be gated.

---

## The Frictionless Horizon

The author who put a pirate flag on his website saw the future clearly: **Friction is the enemy, not the technology.**

The revolution isn't the tool itself. It’s the barriers it removes from the work.

---
# TITLE: Claiming Your Digital Seats: Accounts To Occupy
## Date: 2026-02-04
## Excerpt: Freezing your credit is only half the battle. Your records at the IRS, SSA, and USPS already exist in databases, waiting to be claimed. If you don't register these accounts first, adversaries will. Here are the three critical digital 'seats' you must occupy immediately to secure your identity. 

The data exists. The login is up for grabs.

Freezing credit is foundational, but it’s purely defensive. It ignores the other side of the problem: **the accounts that are already open and waiting to be claimed. **

For critical services like the IRS, SSA, or USPS, your record is already in the database. The portal to access it is live. By creating the account, we are claiming access to an existing identity.

Think of these records as **empty seats at a table.**

If you don’t register for the portal, that seat sits empty. The first person to sit down (whether that is you or an adversary) controls the account. If you leave it vacant, you are waiting for someone else to walk in, sit down, and lock you out.

I view claiming these seats not as admin work, but as a **critical security upgrade**. You are replacing weak security (static data and blind trust) with active defenses (monitoring and passkeys).

## The Three Seats to Occupy Immediately

Here are the three seats I prioritize occupying immediately to secure your digital footprint:

### 1. USPS Informed Delivery

You usually don't know a letter was stolen because you didn't know it was coming in the first place. Informed Delivery fixes this by emailing you scans of your incoming envelopes every morning.

It gives you visibility. If the digital image shows a tax document or a replacement credit card that never physically arrives in your mailbox, you know immediately that something is wrong.

### 2. IRS.gov

This account controls access to your tax transcripts and filing history. Leaving it unclaimed invites tax refund fraud. Claiming it lets you lock the front door with passkeys, ensuring that even if someone has your SSN, they can't get in.

- **Identity Protection PIN (IP PIN)**: Once you are logged in, be sure to generate an IP PIN. This acts as a mandatory 6-digit "password" for your tax return, guaranteeing that any filing submitted without it gets rejected on the spot.

### 3. SSA.gov (Social Security)

Legacy SSA logins were officially retired in 2025. You now must use _ID.me_ or _Login.gov_. If you don't establish this link, an attacker can do it for you. Secure this account with passkeys.

## Defensive Freezes vs. Active Claims

Freezing credit stops new accounts from being created. Filling these empty seats secures the accounts that effectively **already exist**. Don't leave them vacant.

---
# TITLE: Starkiller: The Rise of Weaponized Remote Browsers in Phishing-as-a-Service
## Date: 2026-01-25
## Excerpt: Weaponized Remote Browsers like 'Starkiller' represent a dangerous evolution in Phishing-as-a-Service (PhaaS). By spinning up headless Chromium containers for each victim, they bypass traditional device recognition and legacy OTPs. Here is how they work and how to configure phishing-resistant defenses.

We are seeing a new evolution in phishing architecture. For years, the foundational technology for MFA bypass has been the Go-based reverse proxy framework (like Evilginx or _Modlishka_). Those open-source tools eventually spawned a massive, competitive commercial ecosystem of Phishing-as-a-Service (PhaaS) platforms. Kits like EvilProxy_**, **_W3LL, and _**Tycoon **_commoditized AiTM (Adversary-in-the-Middle) attacks for the masses.

But recent intelligence on a new PhaaS platform called **"Starkiller"** (sold by a group calling itself **Jinkusu**) points to a heavier, highly automated addition to the adversary toolkit: **Weaponized Remote Browsers**.

## The Architecture

Most modern phishing kits abandoned static HTML templates years ago in favor of reverse proxies that route traffic directly to the legitimate site. Starkiller takes a completely different architectural approach.

Instead of acting as a pass-through proxy forwarding web packets, **it spins up a dedicated, headless Chromium instance inside a Docker container for every victim.** You are essentially interacting with a remote browser that is navigating the real site on your behalf.

The victim sees the real site rendered perfectly. Because the actual login interaction happens server-side, it breaks standard device recognition. The Identity Provider (IdP) sees the fingerprint of the attacker's Dockerized browser, not the victim's local machine.

## Automated Delivery at Scale

Starkiller is built for scale and distributed like a SaaS product, automating the Docker engine status, image builds, and container scaling entirely.

For delivery, it relies heavily on email. To hide the malicious destination, operators use a built-in URL Masker that abuses the classic `@` symbol basic authentication syntax combined with URL shorteners. To make matters worse, the kit includes an email harvesting capability that scrapes contact lists from compromised sessions to automatically build target lists for the next wave of internal phishing.

## The Hardware Key Reality

Marketing materials for these kits claim they can bypass hardware keys "when proxied." This is technically misleading. **You cannot proxy a Passkey or FIDO2 interaction over this setup** because Passkeys are cryptographically bound to the origin domain.

What they are actually exploiting is **Legacy OTP**. If your YubiKey is configured to spit out a text string (the `cccccc...` output), that is just keystrokes, and keystrokes can be relayed in real time. This tool destroys SMS, TOTP, and Legacy OTP, but it fails against proper FIDO2/WebAuthn.

## The Fixes

To defend against this next wave of phishing architecture, organizations must enforce technical controls rather than relying on human detection:

- **Enforce Passkeys (Enforced)**: This is the strongest architectural defense available. Because Passkeys rely on origin binding, they fundamentally break the "Remote Browser" proxy model. The attacker's container cannot trick your device into signing a request for a domain you aren't physically visiting. *Note: You must enforce Passkeys as the only method; leaving them optional leaves the door wide open.*
- **Stop Accepting Legacy OTPs**: The flaw exists entirely within the IdP configuration. If your IdP still accepts the "Yubico OTP" text string (the `cccccc...` output) for authentication, you are phishable. If you configure your IdP to only accept FIDO2/WebAuthn, the door is locked.
- **Device Trust**: Since the browser is actually running inside the attacker's Docker container, it lacks your managed device certificate. Enforcing mTLS/Device Compliance at the IdP level acts as a major roadblock (though bypasses are eventually found here).
- **Training is Insufficient**: Between the URL masker hiding the true domain and the visual fidelity being a perfect live match of the real site, we have to be realistic. Even well-trained experts can slip. We need technical controls that do not rely on human perception.

---
# TITLE: The Homograph Mirage: Why Hovering Over Links is Bad Security Advice
## Date: 2026-01-14
## Excerpt: Telling users to spot lookalike Unicode domains (IDN Homograph attacks) by hovering over links is outdated and ineffective advice. Modern browsers solved this years ago by displaying the raw Punycode. Here is why we should rely on browser engineering rather than visual eye tests.

This kind of "spot the difference" advice is making the rounds again.

It is well-intentioned, but it ignores almost a decade of browser engineering.

The screenshot warns about **IDN Homograph attacks**—where an attacker uses lookalike characters (like a Cyrillic "o") to spoof a domain like `google.com`.

The advice is to "stay sharp" and "hover over links."

Here is why that is bad advice:

### 1. The Human Parser is Defective

You cannot ask users to spot pixel-level differences in fonts. That is a failed security strategy. Human eyes are not compilers, and expecting them to catch micro-visual discrepancies on a mobile screen is unrealistic.

### 2. The Browser Already Solved This

You don't have to spot the difference. Browser vendors largely solved this issue years ago.

If you actually click that "fake" link in any modern browser (Chrome, Edge, Safari, Firefox), the browser detects the mixed-script character set. It sees you are an English-locale user trying to visit a domain mixing Latin and Cyrillic characters.

The browser immediately strips the disguise and renders the raw **Punycode** in the address bar.

So instead of `google.com`, the user sees:

```text
xn--gogle-6xd.com
```

## Where the Illusion Persists

The risk today is mostly in "unmanaged" rendering surfaces like **SMS**, **Slack**, or **social media link previews**. These apps prioritize typography over security policy, so the spoof looks real.

But once the user actually clicks, the browser usually kills the illusion immediately.

## Technical Defenses, Not Eye Tests

We need to stop telling users that security is a game of **"I Spy"** they have to win every single time. It is an engineering problem, and fortunately, the browser engineers are winning.

---
# TITLE: The Performance Cost of Telemetry: Why Your Smart TV is Lagging
## Date: 2026-01-04
## Excerpt: Privacy fatigue often leads to a passive acceptance of background tracking. But surveillance isn't free—it costs CPU cycles and RAM. On underpowered Smart TVs, default Automatic Content Recognition (ACR) settings actively degrade interface performance. Here is how to disable the telemetry scrape and reclaim a responsive UI. 

I often hear people express **"Privacy Nihilism"**—the idea that their data is already exposed, so why bother securing the rest? While I understand the fatigue, there is a tangible cost to this apathy beyond just abstract privacy: **Performance. **

Surveillance costs compute.

If your Smart TV feels sluggish or the user interface is lagging, it is likely a resource contention issue. These devices run on underpowered processors with limited RAM. When you leave default privacy settings enabled—specifically **Automatic Content Recognition (ACR)**—you are forcing that constrained hardware to actively sample pixels and upload fingerprints in the background.

You are effectively spending your CPU cycles on telemetry rather than the user interface.

## Reclaiming Your CPU Cycles

To reclaim your device's performance, prioritize these two actions immediately:

### 1. Stop the Scrape (Disable ACR)

Go to your TV's **Settings > Privacy** (often hidden under options like _"Viewing Data"_, _"Viewing Information Services"_, or _"Smart Interactivity"_) and disable ACR.

This stops the background service from taking screenshots, analyzing display frame buffers, and negotiating network handshakes while you watch.

### 2. Flush the Cache (Cold Boot)

TV operating systems (like Tizen, webOS, or Android TV) are notoriously bad at memory management. Over time, memory leaks pile up.

If the UI remains laggy after disabling telemetry, the system needs a reboot. Don't just press the remote's power button (which usually just puts the TV to sleep). **Pull the physical power cord for 60 seconds** to drain the capacitors and force a clean, cold boot.

## Lag is the Reality

Privacy is abstract, but menu lag is reality. Fix the settings to fix the lag.

---
# END OF DOCUMENT