BOFs, or Beacon Object Files, are small compiled C object files that Cobalt Strike can load and run inside an existing Beacon process. They extend Beacon with focused post-exploitation tasks without creating a separate executable for each action. For defenders, BOFs matter because they change detection trade-offs. You need to look at behaviour, memory, API use, identity activity, network patterns, and testing scope.
If you’ve seen BOFs in a red-team report, detection rule, or Cobalt Strike discussion, the term can sound more complex than it is.
The concept is simple. BOFs help run focused tasks after access has already been gained. That makes them relevant to security teams that need to understand what happens after attackers exploit the first weakness.
This guide explains BOFs without code, commands, payloads, build steps, or evasion advice. The goal is clear understanding, not operator training.
What Are BOFs?
A Beacon Object File, or BOF, is a small compiled C object file that Cobalt Strike can load and run inside an existing Beacon process.
Fortra’s Cobalt Strike documentation defines a BOF as a compiled C program that executes within Beacon and uses internal Beacon APIs. It also describes BOFs as a way to extend Beacon with post-exploitation features.
Beacon is the Cobalt Strike agent that runs in a target environment during authorised security testing or, in malicious hands, during an intrusion. BOFs extend what an agent can do after they’ve gained access.
In essence, a BOF is a small task module for Beacon.
Instead of launching a separate executable for every post-exploitation task, Beacon loads a focused object file into its own process and runs it there.
That’s why BOFs often come up during internal penetration testing. They sit in the phase after initial access; here the question shifts from “can we get in?” to “what can this access reach?"
Why BOFs Were Created: The Fork-and-Run Problem
Before BOFs, many post-exploitation tasks used a fork-and-run pattern.
In simple terms, a tool would create a separate process, run or inject code, collect the result, and send it back. That pattern creates useful signals for defenders, such as process creation, command-line artefacts, injection behaviour, and unusual parent-child process relationships.
Fortra describes BOFs as having a lighter footprint because they run within the Beacon process, rather than requiring a separate process for every post-exploitation action.
That doesn’t make BOFs invisible.
It means they reduce some observable process-creation signals. The detection surface changes. Defenders need to look at memory behaviour, API activity, Beacon context, identity use, and network patterns.
Less process noise never means no evidence.
How BOFs Work Inside Cobalt Strike Beacon
Cobalt Strike introduced the BOF subsystem in version 4.1 on 25 June 2020. The release notes describe a BOF as a compiled C program that executes within Beacon and can call Win32 and Beacon APIs.
A safe, high-level view looks like this:
- Beacon is already running in a target context.
- A small compiled object file is loaded for a specific task.
- Beacon handles the runtime loading work.
- The task runs inside the Beacon process.
- Output is returned.
- The task exits.
For a beginner, the key idea is enough. BOFs run focused post-exploitation tasks without turning each action into a separate executable or child process.
In authorised testing, those tasks support situational awareness, host checks, or controlled validation. The goal should be narrow evidence, not unnecessary activity.
BOFs, COFF Loading, and Dynamic Function Resolution
Internally, BOFs are object files produced by a C compiler. On Windows, BOFs are commonly compiled as COFF object files, a format used by Windows development toolchains.
You don’t need COFF internals to understand the risk. The practical point is that Cobalt Strike handles the linking and loading work at runtime. That’s why BOFs stay small and task-specific.
Dynamic Function Resolution, or DFR, is part of the same picture.
At a high level, DFR helps Beacon resolve specific Windows API functions and make them available to the BOF before it runs.
This matters for defenders because BOFs still interact with the operating system to do useful work. They reduce some process signals, but they don’t remove the behaviour.
BOFs Are No Longer Only a Cobalt Strike Topic
BOFs started as a Cobalt Strike feature, but the wider C2 ecosystem now includes BOF-style or COFF-loading support in other tools.
Compatibility isn’t always clean. Loaders, APIs, argument handling, and Beacon API support differ across frameworks.
For defenders, the concept matters more than one product name. Detecting one tool won’t cover every BOF-style execution path.
Why BOFs Change Detection
BOFs change detection because they reduce some signals defenders often rely on.
A fork-and-run pattern exposes new processes, command lines, suspicious parent-child relationships, or injection activity. A BOF runs inside the existing Beacon process, so those signals won’t always appear in the same way.
That shifts the work.
In practice, defenders need to connect endpoint, identity, network, alert, and device telemetry rather than treating BOF activity as a single-file detection problem.
Useful review areas include:
- Endpoint telemetry.
- Memory-related alerts, such as suspicious executable memory regions.
- API behaviour.
- Process lineage.
- Image load events.
- Network egress.
- Identity use.
- Administrative activity.
- Beacon-like communication patterns.
- Unusual activity from a compromised user context.
No single signal tells the full story. Strong detection comes from joining the context.
Why BOFs Aren’t Invisible
It’s inaccurate to say BOFs bypass EDR as a general rule.
They reduce some file-based and process-creation signals. Modern endpoint tools also inspect behaviour, memory patterns, suspicious API use, network activity, process context, loaded modules, and identity-linked activity.
Detection depends on tooling, configuration, logging depth, exclusions, alert tuning, response process, and the behaviour being tested.
A poorly scoped action may trigger alerts. A narrow action may still leave useful traces. A mature SOC may detect behaviours that a basic scanner would miss.
The practical question isn’t “can this tool evade detection?”
The better question is:
What did our controls see, what did they miss, and which evidence proves that answer?
That’s where controlled testing has value.
The Stability Risk
BOFs also carry operational risk.
Because they execute inside Beacon, a poorly written or incompatible BOF can crash the agent and cut off access. That matters during authorised testing.
Post-exploitation work needs experienced judgement, clear boundaries, and stop conditions before activity begins.
Tool skill isn’t enough. The tester needs to know when a technique proves risk and when it creates avoidable danger.
What Safe, Authorised Testing Should Define
Post-exploitation testing needs clear boundaries.
The NCSC says a suitably qualified penetration testing team should guide selection and scoping where targeted assurance is needed. It also describes a model engagement as initial engagement, scoping, testing, reporting, and follow-up.
For any engagement where BOF-style techniques are relevant, the scope should define:
- Which systems are in scope.
- Which post-exploitation activities are allowed.
- What data can be accessed or copied.
- What would count as meaningful detection.
- Which techniques need written approval.
- What telemetry the blue team should collect.
- Which accounts may be used.
- What safety limits apply to production systems.
- What stop conditions apply.
- How findings will be documented and verified.
This approach protects your systems and improves the report. The work should prove risk without creating avoidable operational danger.
Common Misunderstandings About BOFs
Are BOFs Malware?
A BOF is a file format and execution model used with Beacon. Context matters.
- In an authorised penetration test, activity is scoped, approved, logged, and reported.
- In an unauthorised intrusion, a similar capability is malicious.
Intent, permission, and behaviour change the meaning.
Do BOFs Bypass EDR?
No blanket claim would be accurate.
BOFs reduce some file and process-creation signals. That’s different from bypassing EDR. Modern detection still uses endpoint telemetry, memory inspection, API behaviour, network activity, and identity context.
Are BOFs Written in C or C++?
The clean definition starts with C because Fortra defines BOFs as compiled C programs. Some templates and workflows support C++ patterns, but C is the baseline definition.
Does Every Penetration Test Need BOFs?
No. Testing should match your risk model. Some environments need deeper post-exploitation validation. Others need application testing, cloud review, code audits, or perimeter testing first.
The right question is "What evidence do we need?” not "Which tool sounds advanced?
What a Useful BOF-Related Finding Should Prove
A useful BOF-related finding should do more than say a BOF-style technique was used.
It should explain
- The starting access level,
- The approved action,
- What controls detected,
- The system context,
- The evidence collected,
- What they missed, and
- Which fix would reduce the risk.
This is where scoped manual testing matters. 7ASecurity helps teams test post-exploitation paths with clear boundaries, practical evidence, and fix verification so the report supports real security decisions instead of only describing tool activity.
A strong finding should answer one question clearly: what did this access prove that the team can now fix, monitor, or contain?
Need to Define a Safe Post-Exploitation Scope?
7ASecurity can help you plan a manual penetration test with clear boundaries, evidence rules, and practical remediation guidance. It starts with a free conversation.
Plan a Scoped Penetration Test
FAQs
Are BOFs the Same as Beacon?
No. Beacon is the Cobalt Strike agent. BOFs are small object files that run inside Beacon to extend its post-exploitation capability.
Why Do Defenders Care About BOFs?
Defenders care because BOFs reduce some process-creation signals. Detection needs endpoint telemetry, memory context, API behaviour, identity signals, and network analysis.
Can BOFs Be Detected Before They Run?
Sometimes, but it depends on the environment and delivery path. Often, useful detection comes from runtime behaviour, endpoint telemetry, memory signals, or Beacon activity.
What Should a Report Say About BOFs?
A useful report should explain the starting point, permission level, tested action, evidence, detection response, risk, fix path, and retest result. “BOF used” isn’t enough.
What Should We Agree Before BOF-Style Testing?
Agree the scope, approval process, testing window, accounts, safety limits, telemetry goals, stop conditions, evidence rules, and reporting format before testing starts.
Turn Post-Exploitation Evidence Into Safer Systems
When your team understands BOFs, they can ask better questions about what happens after threat actors gain access.
7ASecurity can help you test internal and external security with a clear scope, careful evidence, and practical fix guidance.
