What is a Software Bill of Materials (SBOM)
All right, so I am happy to announce another tool. There are plenty of reasons why you’d want this. I pronounce it as ‘SBOMify’ (or S-B-O-M-I). SBOMs are Software Bills of Materials.
What is an SBOM? The term is often misunderstood; you might think it’s just an inventory of purchased software, but it’s much more than that. An SBOM contains what we call software components. It includes the component name and the type: application, library, framework, or firmware.
Let’s use a commonly exploited application that has loads of vulnerabilities, even though no one uses it anymore: SLMail 5.5. It is one of the most basic OffSec or Corelan training materials for simple buffer overflows and memory corruption. It involves an X amount of bytes overwriting the Extended Instruction Pointer (EIP), which then points to shellcode. It’s quite versatile for trying out different exploits.
But that’s not the point. SLMail 5.5 is the application, but in the training material—which is now regularly seen on YouTube or Udemy—they use what’s called a DLL (a library). That specific library was not protected by Data Execution Prevention (DEP) or ASLR. Because the base address in that DLL is static, you can grab API calls or even try out ROP chaining.
I’m just explaining the component types: the application is SLMail, and the library is a custom DLL unprotected by modern mitigations. We also have version numbers because you can parse digital signatures and signing certificates to find who compiled it. Certificates contain manufacturer and vendor information, which applies to the supplier and origin.
Within this library, attempting to patch a vulnerability can create dependency breakages. A DLL has an Import Address Table (IAT) and an Export Address Table (EAT). Normally, DLLs are compiled to depend on other binaries (imports) and export their own functions (exports). You can use the dumpbin /exports command to see what SLMail 5.5 is using.
Because we can tie a CVE to a publicly known exploit, you can use our tool to identify the CVE. This isn’t exactly an exploit validation framework—that was the combination of VibeScan and FridaGuard. This is a static tool for compliance reasons.
There are strict deadlines in jurisdictions like Europe; by 2026 and 2027, they will have specific requirements for compliance. If you aren’t compliant, that’s how CVEs and 0-days emerge. There are articles now about people using AI to weaponize non-disclosed vulnerabilities to write a 0-day before a patch is released.
SBOMs also provide cryptographic integrity data. This is found by extracting the certificate and running a checksum (like a SHA hash) on the binaries. You can’t arbitrarily modify a certificate because it is signed to a specific hash.
For legal compliance, SBOMs include license types (Free, GPL, Proprietary). Legal teams care about this because misusing or modifying a library without consent can lead to serious legal trouble.
We also need build metadata, such as the tool used to generate it (e.g., Visual Studio 2022). This is vital. If you compiled software using Visual Studio 2008, the default mitigations in cl.exe were not activated. Back then, you barely had more than basic stack mitigations.
You can also validate the author, organization, product name, and version. For example, ntoskrnl.exe is the Windows NT kernel. By parsing headers, you verify the kernel is legitimate and trace vulnerabilities to a specific build. For instance, recent Windows 10 patches defeated classic ‘Previous Mode’ (God Mode) exploits. Using a vulnerable driver, you could briefly load an exploit, grab the primitive, and unload the driver so it’s no longer on disk.
That is the importance of an SBOM. It is static, but it works as an add-on to VibeScan. While VibeScan uses Semgrep rules to trace crashes and vulnerabilities in source code, and FridaGuard validates them, SBOMify maps and verifies those vulnerabilities against actual CVEs. That is what a real Software Bill of Materials actually means.
Components of SBOMify and why it is necessary from notable legal battles
So for now, what are the components? There are three components that represent 90% of SBOMify’s capabilities.
The first two are Syft (S-Y-F-T) and Grype (G-R-Y-P-E). Both are designed to integrate with Docker, so we can skeletonize the framework to make it more efficient. I have already demonstrated that the static rule sets for VibeScan (which are Semgrep rules) are remarkably large, but they don’t always look for the specific software bugs or vulnerabilities we need. VibeScan is security-based, but we need to pad it with custom Semgrep rules. Every company that uses Semgrep has its own private set of rules to stay competitive and mitigate exploits to stop widespread abuse. For example, a group might have their hands on properly disclosed vulnerabilities so that no one can simply weaponize them based on a basic description.
We are using Syft and Grype. Grype is the vulnerability scanner for container images and file systems; it naturally supports Docker, uses threat and risk prioritization, and has its own reporting format. Syft allows you to generate machine-readable SBOMs in multiple formats—some are generic, while others focus on vulnerability reporting.
Now, what people are often unaware of is FOSSology. FOSSology effectively checks licenses; it is an open-source license compliance software system and toolkit. This is where the legal compliance portion of SBOMify is critical. As I mentioned before, if you improperly use or acquire a library, you can be sued.
There are famous cases of people being sued for illegally modifying or using libraries. If you remember the PC version of Grand Theft Auto V, people were confronted at their doorsteps for modifying textures or releasing mod menus. By modifying, injecting into, or altering libraries to make character models do unintended things, they opened themselves up to legal action.
Some have even faced criminal charges, as covered by Darknet Diaries. In one case involving video game cheating, the FBI arrested an individual and put him in federal prison—not just for the cheats, but for cracking tens of thousands of games. Developers like Nintendo and Sony go after these people not just because of cheating (which is often a civil matter), but because the FBI can charge cheat makers with theft if they are cracking and distributing pirated games alongside their software.
Front end design
Since we are announcing our new product, we might as well tell you how the engine works. By default, VibeScan comes with optional selectors to enable SBOMify. You simply click a slider, and depending on the plan you subscribe to—likely on a commercial site like Gumroad initially for unit testing—you get a set number of scans per month.
For FridaGuard, the process depends on whether the code is natively compiled or interpreted. We support the top 10 programming languages. C and C++ are still incredibly popular because high-stakes environments, such as NASA or Lockheed Martin fighter jet systems, require ‘unsafe’ programming to minimize latency. We fully support C.
Since FridaGuard hooks into native code or an intermediate runtime like the .NET CLR, it also supports the engines behind TypeScript and the Java compiler. Because of this, FridaGuard requires an intermediary compiler container that will be cold-started to compile and proxy the final product and its dependencies before piping them into FridaGuard.
Ultimately, we are also allowing users to specify custom functions. FridaGuard will automatically append vulnerable functions identified by Semgrep and SBOMify output. Since VibeScan and SBOMify are static testing tools (SAST), and FridaGuard acts as a form of DAST and IAST, the integration is seamless. FridaGuard will not only parse and instrument automatically identified vulnerabilities but also any specific function you define, provided you specify the file and function name.
FridaGuard is our main competitive advantage (Dynamic Binary Instrumentation)
At least three products in our development—VibeScan, FridaGuard, and SBOMify—are vertically integrated. You simply click a selector; based on your plan, certain selectors may be grayed out. You have a set amount of credits depending on your subscription tier, whereas the basic plan might only include VibeScan.
The pricing model gives you X amount of runs. Because it is very low-cost for me to run these containers, the monthly fee remains competitive. VibeScan will offer the highest number of available credits, while FridaGuard and SBOMify—the other two vertically integrated products in our stack—will use credits at a different rate. This allows you to quickly generate reports in PDF and other industry-standard formats for SBOM compliance and vulnerability checking.
We are filling a niche. While automation engineers could integrate these into their own in-house tools, I agree with the case made by John Strand regarding what he calls ‘mediocre’ Software as a Service. It reminds me of the Bell Labs days, where everyone had proprietary in-house products that weren’t necessarily comprehensive or validated.
Almost no one outside of a very specific subset of reverse engineers uses Frida regularly. Most people who reverse engineer binaries or web applications rarely touch it. To this point, Frida has been relegated to specialists in Dynamic Binary Instrumentation (DBI) and middleware hooking. Since 2023, it has been perceived as an ‘arcane black box.’ Very few people have automated or dynamically modified a Frida agent based on customer specifications through a simple, ‘click-and-go’ web GUI.
Modern Attack Chains can be solo’d with incredible difficulty but commitment
This is ultimately a conflated, top-down view of modern exploitation techniques—from the initial foothold and entry points to Remote Code Execution (RCE) within a privileged host, allowing full system compromise, pivoting, and lateral movement across the network.
Modern exploitation is very hard to automate, though I have achieved this under specific conditions. It often starts with a web-based foothold from a front-facing server, assuming we are using exploitation rather than social engineering like spear-phishing. For example, if I used a SharePoint exploit to gain shell access on a front-end server, that server is likely utilizing Cloud APIs. I could then automate the harvesting and modification of tokens using Microsoft Graph abuse techniques.
From this foothold, I may discover Active Directory (AD) instances and propagate through the network using AD abuse. Depending on the privileges gained, I can automate tools like Rubeus to extract Kerberos tickets or privileged keys from memory to move laterally.
Furthermore, native code execution—distinct from web code—can be achieved by chaining multiple exploits within a state machine. This state machine tracks the exploitation phases. We aren’t using a stack machine for VM obfuscation, but rather chaining Local Privilege Escalation (LPE) vulnerabilities to gain administrative rights.
For instance, I can inject code after grabbing process handles and self-escalating privileges, as I detailed in my previous article regarding the Notepad (pre-8.8.1) LPE exploit. This method involved using regsvr32 to register a local object, but it specifically involved dropping a .NET binary masquerading as regsvr32.exe to run an arbitrary command as an administrator.
Once administrative access is secured, I can use binary exploits to load malicious kernel drivers, escalate to SYSTEM, and grant myself Protected Process (PP/PPL) privileges. I can then hide the PowerShell process using a rootkit like r77. This broad overview shows how, by landing on an on-premise AD environment after abusing Graph tokens, one can transition from the Cloud to the local environment and automate the final stages of Active Directory compromise.
My credentials
Now, I’m not trying to fearmonger here, but if I am able to do this, you should listen. I am the author of ‘Ultimate Cyber Warfare for Evasive Cyber Tactics’ by OrangeAVA Publication. During the writing of that book, much of the original content I developed was not included. My technical reviewer mentioned that even what was published was difficult enough; what I write on my blog regarding offensive security is on another level entirely.
Since then, I have refined my knowledge. People act as if offensive operations are a black box. What I did was flatten the ‘skill floor’ to raise my beginner concepts to an intermediate level, and my intermediate skills to expert. For the expert-level tradecraft, I kept it intentionally obfuscated. In offensive operations, you chain exploits and automated privilege escalation. You use Bring Your Own Vulnerable Driver (BYOVD) attacks after Bring Your Own Vulnerable App (BYOVA) attacks, and the box only gets darker.
In the past, being able to perform a buffer overflow on a late-2000s mail server using POP3 was all it took to get a job at a government contractor like Booz Allen Hamilton. You didn’t even need a GXPN; they would have paid for your certifications. Back then, even that was seen as mystical.
If what I’m telling you is intimidating, remember that motivated threat actors are teaming up to sell exploit toolkits, like the Rig Exploit Kit. The ecosystem has become frighteningly powerful through automation. Meanwhile, standards are being lowered as companies ‘bolt’ AI onto their software suites, expanding the attack surface.
Unlike our competitors, we DO NOT use public or custom AI models. There is a reason for this: I know the importance of fact-checking and validation. We’ve seen ‘AI-generated slop’ and fraudulent presentations at DefCon and Black Hat. Look at Crown Sterling in 2019, where they invented terms like ‘quasi-prime numbers’ and were interrupted by a furious cryptographer. This level of nonsense exploits ignorance.
My book, Ultimate Cyber Warfare for Evasive Cyber Tactics, is in the National Library of Israel, but even I will tell you it is outdated. It is an entry-level standard. It still describes dropping obfuscated binaries to disk. Today, you wouldn’t get far without improving those concepts. At a minimum, you need to use D/Invoke, JIT stomping, or JIT overwriting of native code within fileless malware. To evade EDR or migrate processes, you must use Heaven’s Gate techniques to obfuscate via direct or indirect syscalls, or proxying them behind API calls. If you don’t understand what I just told you, guess what? The attackers coming for you are learning it very quickly.
