When I first wrote about Sliver beacons in purple teaming, the point was simple: implants aren’t just red-team toys, they’re teaching tools for defenders. Now let’s level up the fun factor and the fidelity. Meet Sliver Armory BOFs, tiny, in-memory payloads you can load into a beacon and run like tiny ninja functions.
This post explains what BOFs are, why you want to run them from a beacon instead of dropping a binary to disk, and it showcases a small, curated sample of Sliver Armory BOFs that I ran in the lab. It’s short, punchy, and full of things you can hand over to your IR team and say: “Here! Catch this!”
First Things First: Spin Up a Beacon
Before you can run BOFs from your beacon, you need a beacon. Below is a friendly screenshot of the exact moment you generate a Windows beacon binary from Sliver, because you deserve a moment of ASCII art glory before the chaos. Save that EXE somewhere obvious, and don’t forget a strong coffee.
What the heck is a BOF?
BOF = Beacon Object File.
They’re lightweight, compiled C snippets that the beacon can load and execute directly in memory. Tiny, focused, and fast. Want to enumerate services? There’s a BOF. Want to poke Kerberos tickets? There’s a BOF. Want to unhook AMSI? You guessed it. BOF!
Quick characteristics:
Runs in memory inside the beacon process.
No EXE on disk: no file creation, no obvious artifact trail.
Single-purpose: one job, do it quickly, exit.
Highly portable: many BOFs originally for Cobalt Strike are compatible with Sliver; Armory curates Sliver-ready stuff.
Why run a BOF from the beacon instead of dropping tools on disk?
Short version: stealth + repeatability + realism.
No file fingerprints. Drop winpeas.exe on disk and your AV/EDR lights up like a Christmas tree. Run the same checks via a BOF and you may only see memory and handle activity.
Cleaner telemetry. BOFs keep the noise low. You’ll surface the technique (memory reads, registry queries, token ops) not the toy (the filename). That forces defenders to detect what matters.
Fast, repeatable tests. BOFs are tiny: run them a dozen times in an exercise, tweak a rule, run again. Rinse & repeat. Perfect for simulate → detect → tune → repeat.
Technique fidelity without tool bias. If your SOC only spots winpeas.exe, they’ll pat themselves on the back, but they might miss the same behavior executed in-memory. BOFs help you test for technique.
Seatbelt as a BOF vs WinPEAS: the demo everyone gets
Imagine you want to test host discovery detections. Two ways to do it:
WinPEAS from disk: drop winpeas.exe, run it, parse output. Good for POC of file-based detections, but noisy and biased toward file-signature detections.
Seatbelt as a BOF: same type of reconnaissance (services, registry keys, installed apps, users) but runs in memory. Same functional output, different telemetry: memory access, registry/WMI calls, no new EXE. Seatbelt won’t call out every privesc vector WinPEAS does, but it will enumerate the host surface you need to find escalation paths.
Which test is more meaningful? If your SOC only caught WinPEAS, you’ve got a gap. If your SOC caught Seatbelt behavior (unusual registry/WMI activity, host-survey cadence), you’ve got technique coverage.
Delivery & a little automation: scheduled-task style
We dropped our little beacon payload on the target, then crafted a fun scheduled task set to run at logon. Log out, log back in, cue the triumphant beacon callback to Sliver.
Scheduled task created. Logout → logon → beacon: incoming!
Showcasing Armory BOFs
For the BOF showcase in this post, I used Phil Keeble’s AWS-RedTeam_ADLab to spin up an AD environment in AWS (domain controllers, servers, users/groups). It provides the telemetry and domain behavior needed to play with BOFs.
Below is a small sample of Sliver Armory BOFs I ran for this post that are quick, repeatable, and high-signal. Technically these are .NET-based tools, but in the context of Sliver Armory they are used in a BOF-life fashion where they are loaded in memory via the beacon.
Seatbelt — in-memory host surveys (recon)
Why run it: Host discovery telemetry without a disk artifact. Great to test detections for system enumeration.
Common Armory flow (within Sliver):
sliver> armory install seatbelt
sliver> sessions
sliver> use <SESSION_ID>
sliver(PROPOSED_IMPRESS)> seatbelt – -group=all
sliver(PROPOSED_IMPRESS)> seatbelt OsInfo
sliver(PROPOSED_IMPRESS)> seatbelt LogonSessions
sliver(PROPOSED_IMPRESS)> seatbelt ScheduledTasks
sliver(PROPOSED_IMPRESS)> seatbelt Hotfixes
What it finds: OS info, current logon sessions, scheduled tasks (including your task), installed hotfixes. Functionally similar outputs to WinPEAS but in-memory.
Detection starters: registry/WMI query spikes, unusual host-survey cadence from a single endpoint, PowerShell invocation patterns for enumeration.
Rubeus — Kerberos & ticket ops (list / request / inject)
Why run it: To validate DC and workstation telemetry around Kerberos: ticket requests, AS-REP/AS-REP roastable accounts, and ticket forging/usage.
Common Armory flow (within Sliver):
sliver> armory install rubeus
sliver(PROPOSED_IMPRESS)> rubeus kerberoast /domain:first.local /nowrap
sliver(PROPOSED_IMPRESS)> rubeus asreproast /nowrap
# crack hashes with hashcat:
hashcat -m 13100 hashes.txt /usr/share/wordlists/rockyou.txt --force # Kerberoast
hashcat -m 18200 hash2.txt /usr/share/wordlists/rockyou.txt --force # AS-REP
What to look for: unusual TGS/TGT requests (EventID 4768/4769) originating from systems that don’t normally request many tickets; lots of TGS requests for a single SPN; unexpected ticket encryption types; AS-REP requests for non-interactive accounts.
SharpHound — AD relationship mapping & collection
Why this is my favorite replacement for noisy LSASS drama: instead of fighting LSASS protections to get passwords, SharpHound BOF maps the attack surface; sessions, local admins, ACLs, SPNs, and trusts all in-memory, then outputs JSON you can import to BloodHound and instantly visualize attack paths.
Armory flow (inside Sliver):
sliver> armory install sharphound3
sliver(PROPOSED_IMPRESS)> sharp-hound-3
# or run: sliver(PROPOSED_IMPRESS)> sharp-hound-3 -- -c all
After the run: download the *.zip, import it into BloodHound, and start exploring shortest paths to high-value targets.
What to capture / detect:
LDAP query spikes on DCs
Bursts of numerous LDAP reads from a single workstation
Many SMB/RPC connections to DCs or multiple host queries from one source
Enumerates AD data, saves that data as JSON, and bundles it into a bloodhound.zip
Each one is a focused test: run the BOF, capture the memory/process/reg/net signals, then tune your SIEM/EDR to detect the technique. Not the filename, hash, or strings.
BOF → ATT&CK → What to look for (cheat table)
Closing Thoughts
Sliver BOFs aren’t just red team candy. They’re adversary-grade modules that defenders need exposure to now, not later. By running BOFs in purple sessions, we transform them from “stealth payloads” into repeatable, measurable detection opportunities.