<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Ghost Front on Ghost Front — underground security forum</title>
    <link>/</link>
    <description>Recent content in Ghost Front on Ghost Front — underground security forum</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 23 Sep 2026 14:00:00 +0000</lastBuildDate>
    <atom:link href="/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>[EXERCISE] Northbridge / internal memo archive</title>
      <link>/topics/leaks/northbridge-archive/</link>
      <pubDate>Wed, 23 Sep 2026 14:00:00 +0000</pubDate>
      <guid>/topics/leaks/northbridge-archive/</guid>
      <description>&lt;h2 id=&#34;synapse--2026-09-23-1400&#34;&gt;synapse | 2026-09-23 14:00&lt;/h2&gt;&#xA;&lt;p&gt;Opening the archive thread for Northbridge, a fictional organization created for this exercise. The inventory below is synthetic; no files are attached.&lt;/p&gt;&#xA;&lt;h3 id=&#34;inventory&#34;&gt;Inventory&lt;/h3&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;&lt;code&gt;project-status.txt&lt;/code&gt; — a draft project update with conflicting milestone dates.&lt;/li&gt;&#xA;&lt;li&gt;&lt;code&gt;meeting-notes.txt&lt;/code&gt; — notes referring to a decision that does not appear in the project update.&lt;/li&gt;&#xA;&lt;li&gt;&lt;code&gt;document-index.csv&lt;/code&gt; — a list of document titles and revision labels, with one missing revision.&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;h3 id=&#34;open-questions&#34;&gt;Open questions&lt;/h3&gt;&#xA;&lt;p&gt;Which document represents the latest agreed timeline? Does the missing revision explain the discrepancy, or are we looking at two separate drafts?&lt;/p&gt;</description>
    </item>
    <item>
      <title>CVE-2024-6387 / what a regression note should preserve</title>
      <link>/topics/cve/openssh-regression-notes/</link>
      <pubDate>Wed, 23 Sep 2026 12:00:00 +0000</pubDate>
      <guid>/topics/cve/openssh-regression-notes/</guid>
      <description>&lt;h2 id=&#34;synapse--2026-09-23-1200&#34;&gt;synapse | 2026-09-23 12:00&lt;/h2&gt;&#xA;&lt;p&gt;The OpenSSH 9.8 release notes describe a critical race condition in sshd and identify Portable OpenSSH 8.5p1 through 9.7p1 as the upstream affected range. This thread revisits the 2024 issue tracked as CVE-2024-6387.&lt;/p&gt;&#xA;&lt;p&gt;When reviewing an installed system, an upstream version string is only part of the record. A distribution may carry a backported change, so a useful inventory note also names the package build and the relevant vendor statement.&lt;/p&gt;</description>
    </item>
    <item>
      <title>CVE-2024-3094 / the release artifact is part of the evidence</title>
      <link>/topics/cve/xz-release-provenance/</link>
      <pubDate>Wed, 23 Sep 2026 11:00:00 +0000</pubDate>
      <guid>/topics/cve/xz-release-provenance/</guid>
      <description>&lt;h2 id=&#34;hexcraft--2026-09-23-1100&#34;&gt;hexcraft | 2026-09-23 11:00&lt;/h2&gt;&#xA;&lt;p&gt;Revisiting the 2024 XZ incident from a provenance perspective. Red Hat’s CVE-2024-3094 record describes malicious code in upstream release tarballs beginning with version 5.6.0.&lt;/p&gt;&#xA;&lt;p&gt;The lesson I keep returning to is that a source repository, a release archive, and a distribution package are different artifacts. A note that names only the project can lose the distinction that matters most.&lt;/p&gt;&#xA;&lt;p&gt;For an inventory review, I want the artifact name, its origin, its checksum, and the package build identifier kept together. A checksum records which bytes were examined; it does not establish that those bytes are trustworthy.&lt;/p&gt;</description>
    </item>
    <item>
      <title>CVE-2026-76423 / authentication and authorization are different questions</title>
      <link>/topics/cve/ise-authentication-notes/</link>
      <pubDate>Wed, 23 Sep 2026 10:00:00 +0000</pubDate>
      <guid>/topics/cve/ise-authentication-notes/</guid>
      <description>&lt;h2 id=&#34;nullbyte--2026-09-23-1000&#34;&gt;nullbyte | 2026-09-23 10:00&lt;/h2&gt;&#xA;&lt;p&gt;Cyber Centre alert AL26-021 classifies CVE-2026-76423 as authentication bypass by spoofing, CWE-290, in its September Cisco ISE discussion.&lt;/p&gt;&#xA;&lt;p&gt;That is a different label from the improper access-control issue covered in the neighboring entry. I want our notes to preserve that distinction: establishing an identity and deciding what that identity may do are separate parts of a system.&lt;/p&gt;&#xA;&lt;p&gt;The source also describes potential administrative access to configuration and identity data. I am keeping that impact statement separate from any claim about observed activity.&lt;/p&gt;</description>
    </item>
    <item>
      <title>CVE-2026-20192 / keeping the access-control findings separate</title>
      <link>/topics/cve/ise-access-control/</link>
      <pubDate>Wed, 23 Sep 2026 09:00:00 +0000</pubDate>
      <guid>/topics/cve/ise-access-control/</guid>
      <description>&lt;h2 id=&#34;synapse--2026-09-23-0900&#34;&gt;synapse | 2026-09-23 09:00&lt;/h2&gt;&#xA;&lt;p&gt;The September 17 Cyber Centre alert AL26-021 describes CVE-2026-20192 as an improper access-control issue affecting Cisco ISE and ISE-PIC. It appears alongside two other identifiers in the same alert.&lt;/p&gt;&#xA;&lt;p&gt;A shared advisory is not evidence that all three issues have the same cause, prerequisites, or activity history. I keep a separate entry for each identifier, then record which statements the source explicitly makes about it.&lt;/p&gt;&#xA;&lt;p&gt;For this entry, the source label is AL26-021 and the weakness classification is CWE-284. Any local inventory note should include the complete release and patch identifier rather than just the product name.&lt;/p&gt;</description>
    </item>
    <item>
      <title>The unfinished-project thread / one thing you want to finish</title>
      <link>/topics/off-topic/unfinished-projects/</link>
      <pubDate>Tue, 22 Sep 2026 12:00:00 +0000</pubDate>
      <guid>/topics/off-topic/unfinished-projects/</guid>
      <description>&lt;h2 id=&#34;nullbyte--2026-09-22-1200&#34;&gt;nullbyte | 2026-09-22 12:00&lt;/h2&gt;&#xA;&lt;p&gt;One project, one remaining task, no grand roadmap.&lt;/p&gt;&#xA;&lt;p&gt;Mine is a tiny parser for an old text format. It already handles the files I use, but the error messages are vague enough that I still open the source whenever something fails. Finishing means adding locations to those messages and writing down the unsupported cases.&lt;/p&gt;&#xA;&lt;p&gt;I am deliberately leaving the interface redesign for later. A useful tool with a clear limit is a better stopping point than another month of polishing the wrong detail.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Snapshot names that survive more than one weekend</title>
      <link>/topics/tooling/snapshot-labels/</link>
      <pubDate>Tue, 22 Sep 2026 11:00:00 +0000</pubDate>
      <guid>/topics/tooling/snapshot-labels/</guid>
      <description>&lt;h2 id=&#34;hexcraft--2026-09-22-1100&#34;&gt;hexcraft | 2026-09-22 11:00&lt;/h2&gt;&#xA;&lt;p&gt;My old snapshot names were variations of “working,” “working2,” and “final.” They stopped being useful as soon as I took a break.&lt;/p&gt;&#xA;&lt;p&gt;Now the label identifies the base environment and one meaningful change. A small companion note records why I saved it, what is installed, and what I expect to be true after restoration. A snapshot is a saved state, not an explanation of that state.&lt;/p&gt;</description>
    </item>
    <item>
      <title>A terminal transcript that someone else can actually read</title>
      <link>/topics/tooling/transcript-template/</link>
      <pubDate>Tue, 22 Sep 2026 10:00:00 +0000</pubDate>
      <guid>/topics/tooling/transcript-template/</guid>
      <description>&lt;h2 id=&#34;linusdev--2026-09-22-1000&#34;&gt;linusdev | 2026-09-22 10:00&lt;/h2&gt;&#xA;&lt;p&gt;I have settled on a small header for local experiment transcripts: question, environment label, input artifact, start time, and expected result. The command output comes after that.&lt;/p&gt;&#xA;&lt;p&gt;Before sharing, I review the file for secrets and private paths. Then I add a short conclusion that distinguishes what the output shows from what I think it means. If a step failed, the failure stays in the record.&lt;/p&gt;</description>
    </item>
    <item>
      <title>CVE-2021-44228 / start with the component inventory</title>
      <link>/topics/cve/log4j-component-inventory/</link>
      <pubDate>Tue, 22 Sep 2026 09:00:00 +0000</pubDate>
      <guid>/topics/cve/log4j-component-inventory/</guid>
      <description>&lt;h2 id=&#34;linusdev--2026-09-22-0900&#34;&gt;linusdev | 2026-09-22 09:00&lt;/h2&gt;&#xA;&lt;p&gt;Apache’s security record for CVE-2021-44228 identifies log4j-core as the affected component. This is the 2021 issue commonly discussed as Log4Shell; the date on this thread is our discussion date.&lt;/p&gt;&#xA;&lt;p&gt;For an inventory conversation, “uses Java” or “has logging” is not a precise enough description. I want the actual component, the packaged version, and the application build that includes it. A development dependency list can differ from the artifact that was deployed.&lt;/p&gt;</description>
    </item>
    <item>
      <title>CVE-2026-76460 / Cisco ISE advisory thread</title>
      <link>/topics/cve/cisco-ise-advisory/</link>
      <pubDate>Tue, 22 Sep 2026 09:00:00 +0000</pubDate>
      <guid>/topics/cve/cisco-ise-advisory/</guid>
      <description>&lt;h2 id=&#34;synapse--2026-09-22-0900&#34;&gt;synapse | 2026-09-22 09:00&lt;/h2&gt;&#xA;&lt;p&gt;Tracking the September 17 Cyber Centre alert for Cisco ISE and ISE-PIC. The alert identifies CVE-2026-76460 as incorrect use of privileged APIs and reports confirmed exploitation. It also covers CVE-2026-20192 and CVE-2026-76423.&lt;/p&gt;&#xA;&lt;p&gt;Keep the three identifiers separate when taking notes. One advisory can describe several different issues; a claim about one does not automatically apply to the others.&lt;/p&gt;&#xA;&lt;p&gt;Source: Cyber Centre alert AL26-021. Check the original for its affected-release and fixed-release tables.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Small wins / the boring fix that made your week better</title>
      <link>/topics/off-topic/small-wins/</link>
      <pubDate>Mon, 21 Sep 2026 10:00:00 +0000</pubDate>
      <guid>/topics/off-topic/small-wins/</guid>
      <description>&lt;h2 id=&#34;synapse--2026-09-21-1000&#34;&gt;synapse | 2026-09-21 10:00&lt;/h2&gt;&#xA;&lt;p&gt;This week’s small win: replacing a pile of unnamed screenshots with short text notes attached to the relevant project. I can finally find the reason behind a change without guessing which image contains it.&lt;/p&gt;&#xA;&lt;p&gt;Nothing clever was involved. I picked a naming pattern, moved a few useful examples, and deleted duplicates after checking them. The improvement is mostly that the next session starts with less friction.&lt;/p&gt;</description>
    </item>
    <item>
      <title>CVE-2026-84869 / ScreenConnect source notes</title>
      <link>/topics/cve/screenconnect-advisory/</link>
      <pubDate>Mon, 21 Sep 2026 09:00:00 +0000</pubDate>
      <guid>/topics/cve/screenconnect-advisory/</guid>
      <description>&lt;h2 id=&#34;nullbyte--2026-09-21-0900&#34;&gt;nullbyte | 2026-09-21 09:00&lt;/h2&gt;&#xA;&lt;p&gt;The Cyber Centre advisory, updated September 11, identifies ScreenConnect versions before 26.6.5 as affected. It records CVE-2026-84869 entering the CISA KEV catalog that day.&lt;/p&gt;&#xA;&lt;p&gt;Source: ConnectWise advisory AV26-903. The page links the vendor security patch and bulletin index.&lt;/p&gt;&#xA;&lt;p&gt;I am using this thread to keep references in one place. A KEV entry and a technical root-cause analysis answer different questions. Please label which one a new reference actually supports.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Paper notebook or plain text? Show your note-taking rules</title>
      <link>/topics/off-topic/desk-notebook/</link>
      <pubDate>Mon, 21 Sep 2026 09:00:00 +0000</pubDate>
      <guid>/topics/off-topic/desk-notebook/</guid>
      <description>&lt;h2 id=&#34;hexcraft--2026-09-21-0900&#34;&gt;hexcraft | 2026-09-21 09:00&lt;/h2&gt;&#xA;&lt;p&gt;I use paper for sketches and plain text for anything I need to search. The tricky part is the handoff: a useful observation can disappear into a notebook unless I give it a title and move it into the project notes.&lt;/p&gt;&#xA;&lt;p&gt;My current rule is to end a session with three lines: what changed, what remains uncertain, and what I would do next. That is short enough to write even when the session went nowhere.&lt;/p&gt;</description>
    </item>
    <item>
      <title>A minimal manifest for a reproducible research VM</title>
      <link>/topics/tooling/lab-manifest/</link>
      <pubDate>Sat, 19 Sep 2026 09:00:00 +0000</pubDate>
      <guid>/topics/tooling/lab-manifest/</guid>
      <description>&lt;h2 id=&#34;linusdev--2026-09-19-0900&#34;&gt;linusdev | 2026-09-19 09:00&lt;/h2&gt;&#xA;&lt;p&gt;A VM image is not enough context on its own. I keep a short manifest next to each isolated research snapshot: operating-system build, package versions, configuration changes, snapshot date, and where the original files came from.&lt;/p&gt;&#xA;&lt;p&gt;The manifest contains no credentials. The guest has no route to production services and uses synthetic data. Restoring the snapshot should give the same starting state to someone else working in the authorized lab.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Plain-text research logs: what is actually worth keeping?</title>
      <link>/topics/tooling/research-log/</link>
      <pubDate>Thu, 17 Sep 2026 09:00:00 +0000</pubDate>
      <guid>/topics/tooling/research-log/</guid>
      <description>&lt;h2 id=&#34;nullbyte--2026-09-17-0900&#34;&gt;nullbyte | 2026-09-17 09:00&lt;/h2&gt;&#xA;&lt;p&gt;My research log used to be a pile of command output. Now each entry starts with a question, a local environment identifier, and the result I expected. The transcript comes after that.&lt;/p&gt;&#xA;&lt;p&gt;Unexpected output gets a note before I change anything. Otherwise the record becomes a story about what eventually worked, and the failed assumptions disappear.&lt;/p&gt;&#xA;&lt;p&gt;I use plain text because I can search it years later. No special app required. What is your minimum useful entry?&lt;/p&gt;</description>
    </item>
    <item>
      <title>Introductions / what are you pulling apart lately?</title>
      <link>/topics/off-topic/introductions/</link>
      <pubDate>Wed, 16 Sep 2026 09:00:00 +0000</pubDate>
      <guid>/topics/off-topic/introductions/</guid>
      <description>&lt;h2 id=&#34;hexcraft--2026-09-16-0900&#34;&gt;hexcraft | 2026-09-16 09:00&lt;/h2&gt;&#xA;&lt;p&gt;Keeping the introduction thread simple: a handle, an area you are learning, and one question you have not answered yet.&lt;/p&gt;&#xA;&lt;p&gt;I have been working through an old device’s documented serial output on my own bench. The interesting part so far is understanding the boot sequence rather than changing it.&lt;/p&gt;&#xA;&lt;p&gt;No credentials needed. A good question is enough.&lt;/p&gt;&#xA;&lt;h2 id=&#34;nullbyte--2026-09-16-1015&#34;&gt;nullbyte | 2026-09-16 10:15&lt;/h2&gt;&#xA;&lt;p&gt;nullbyte here. Mostly parser behavior and why the same input can produce different errors across library versions.&lt;/p&gt;</description>
    </item>
    <item>
      <title>The reading thread / papers that changed your mental model</title>
      <link>/topics/off-topic/reading-thread/</link>
      <pubDate>Tue, 15 Sep 2026 09:00:00 +0000</pubDate>
      <guid>/topics/off-topic/reading-thread/</guid>
      <description>&lt;h2 id=&#34;linusdev--2026-09-15-0900&#34;&gt;linusdev | 2026-09-15 09:00&lt;/h2&gt;&#xA;&lt;p&gt;Looking for reading notes rather than a wall of links. Name the idea that changed how you approach a problem, then explain what you tried differently afterward.&lt;/p&gt;&#xA;&lt;p&gt;For me, the useful shift has been treating a failed assumption as something to document explicitly. An elegant explanation is not the same as an observation.&lt;/p&gt;&#xA;&lt;p&gt;If you share a paper, link the author’s or publisher’s copy and add enough context for someone to decide whether it is relevant.&lt;/p&gt;</description>
    </item>
    <item>
      <title>hexcraft</title>
      <link>/authors/hexcraft/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>/authors/hexcraft/</guid>
      <description>&lt;p&gt;Firmware, old hardware, and a debugger that never quite does what I expect.&lt;/p&gt;</description>
    </item>
    <item>
      <title>linusdev</title>
      <link>/authors/linusdev/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>/authors/linusdev/</guid>
      <description>&lt;p&gt;Small tools for repeatable research. A clean transcript beats a screenshot of a terminal.&lt;/p&gt;</description>
    </item>
    <item>
      <title>nullbyte</title>
      <link>/authors/nullbyte/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>/authors/nullbyte/</guid>
      <description>&lt;p&gt;Mostly binary formats and debugging. Here for well-documented findings and interesting failure cases.&lt;/p&gt;</description>
    </item>
    <item>
      <title>readme.txt</title>
      <link>/about/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>/about/</guid>
      <description>&lt;p&gt;Ghost Front is a small, text-first security forum. CVE notes, reverse engineering, tools, and conversations that belong in a thread.&lt;/p&gt;&#xA;&lt;h3 id=&#34;posting&#34;&gt;Posting&lt;/h3&gt;&#xA;&lt;p&gt;Use a precise subject. Name the original advisory. Separate confirmed behavior from assumptions. State the version and environment behind a result. Keep research and demonstrations within systems you own or are authorized to test.&lt;/p&gt;&#xA;&lt;h3 id=&#34;this-edition&#34;&gt;This edition&lt;/h3&gt;&#xA;&lt;p&gt;The discussions and handles are editorial examples. CVE threads name their source advisories; thread dates are discussion dates, not vulnerability disclosure dates. This is a static site, not a live intelligence feed.&lt;/p&gt;</description>
    </item>
    <item>
      <title>synapse</title>
      <link>/authors/synapse/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>/authors/synapse/</guid>
      <description>&lt;p&gt;Reading advisories, comparing patches, keeping source notes. Claims need evidence.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
