Offensive Context

Abusing eBPF, Part 1: What even is eBPF?

contact@offensivecontext.com (Evan Anderson) — Tue, 23 Jun 2026 00:00:00 GMT

Welcome to a new series. The last one was about learning DNS while abusing its functionality to do unintuitive things. This one is about doing fun things to the Linux kernel, with the kernel's full cooperation.

We are going to abuse eBPF.

A quick note before we get going. Everything in this series is built and tested on lab boxes I own. Use this stuff on systems you have permission to use it on. That's the only warning you're getting, scroll on.

What is eBPF, actually

Well that is an interesting question. The BPF part was originally Berkley Packet Filter which got extended to eBFP (guess what the e stood for). Now eBPF does much much more than simple packet filtering so they've decided eBFP doesn't stand for anything.

Okay so what is it? eBPF continually evolves for our purposes it is a way to write code that runs sandboxed in the kernel.

The idea is straight forward. You write a tiny program. The kernel runs it through a verifier that proves your program will halt, won't read uninitialized memory, won't dereference arbitrary pointers, and won't loop forever. Once the verifier is happy, the kernel JITs your program to native instructions and attaches it to the events you request. Almost any event, a syscall, an incoming packet, a function entry, a kernel tracepoint. When that event fires, your code runs. In kernel context. Just where we want to be.

The eBPF site has nice diagram of "observability" and "networking" and "security.

What it leaves out, and what we are here to talk about, is that eBPF programs:

See every syscall the box makes.
Can rewrite userspace memory on the way out of a syscall (bpf_probe_write_user).
Can decide what happens to a packet before the network stack has touched it (XDP).
Can redirect a connection to a socket the attacker has stashed (sk_lookup).
Persist after the program that loaded them exits (pinning to bpffs).
Are basically invisible to people who only know about lsmod, kernel modules, and /proc/modules.

Astute readers like yourself may notice that this is a really good list if you happen to be building a rootkit.

Why a red teamer cares

A kernel module would do most of this too. Kernel modules have problems though. Distro kernels increasingly require signed modules. Lockdown LSM blocks unsigned loads. lsmod will rat you out. The build dance is a pain in the ass and version-specific. You also need a compiler toolchain on the box, or you cross-compile and hope the kernel headers match.

eBPF sidesteps almost all of it. The toolchain ships with the kernel. Programs are portable across kernel versions (kind of, we'll get there). You don't need CONFIG_MODULES. Lockdown affects some helpers but not the program loading itself. And lsmod doesn't list a single thing.

You do need CAP_SYS_ADMIN (or CAP_BPF on newer kernels) to load programs.

Why Rust, why aya

There are two ways to write eBPF in 2026. Either you use libbpf with C, or you use aya with Rust.

I picked aya, for a few reasons that matter for offensive work:

Single binary. aya compiles the eBPF program to an ELF object at build time and embeds it in the userspace binary with include_bytes_aligned!. Eventually one static musl-linked binary, no bpftool on the target, no .o files lying around.
Type sharing. The kernel-side program and the userspace loader are both Rust crates in the same workspace. The struct your eBPF code writes into a map is literally the same struct the userspace reads back. No header juggling.
It's Rust. Typical stuff about rust, ecosystem, borrow checker, type checking yada yada. I also don't want to deal with toolchain headaches and setting all of that up.

It's fine if you've never written eBPF or Rust before. We'll move slow and I'll show what does what.

Hello, kernel

Let's write a program. The goal: count every execve on the box and print the count once a second. It's the eBPF equivalent of "hello world," and it actually does something — execve is what fires when anything launches a process, so we get to watch the box's process churn in real time.

The repo lives at code/abusing-ebpf-part-1/ in the blog source. Clone it if you want to follow along.

The workspace

We need two crates: one that compiles to a BPF ELF and runs in the kernel, and one that compiles to a regular x86 binary and runs in userspace.

abusing-ebpf-part-1/
├── Cargo.toml                       # workspace
├── rust-toolchain.toml              # nightly
├── execve-counter-ebpf/             # kernel side
│   ├── Cargo.toml
│   └── src/main.rs
└── execve-counter/                  # userspace side
    ├── Cargo.toml
    ├── build.rs                     # compiles the ebpf crate
    └── src/main.rs

The workspace Cargo.toml:

[workspace]
resolver = "2"
members = ["execve-counter", "execve-counter-ebpf"]
default-members = ["execve-counter"]

[workspace.dependencies]
aya = { version = "0.13", default-features = false }
aya-build = { version = "0.1", default-features = false }
aya-ebpf = { version = "0.1", default-features = false }
anyhow = "1"
cargo_metadata = "0.23"
env_logger = "0.11"
libc = "0.2"
log = "0.4"
tokio = { version = "1", features = ["macros", "rt-multi-thread", "signal", "time"] }

[profile.release]
lto = true
strip = true
codegen-units = 1
panic = "abort"

default-members = ["execve-counter"] matters. The eBPF crate doesn't build for your host target — it builds for bpfel-unknown-none. If you cargo build from the workspace root without setting a default, cargo gets confused. We let build.rs in the userspace crate drive the eBPF build.

You also need nightly Rust and bpf-linker:

rustup install nightly
cargo install bpf-linker

The rust-toolchain.toml in the repo pins all that, so once you cd in, you're set.

The eBPF side

Here the eBPF crate's Cargo.toml names the binary counter-bpf. This fixes a naming collision, if we name the bin the same thing as the package, aya-build ends up trying to copy the compiled BPF object on top of its own intermediate target directory and you get a confusing "Is a directory" error.

execve-counter-ebpf/Cargo.toml

[package]
name = "execve-counter-ebpf"
version = "0.1.0"
edition = "2021"
publish = false

[dependencies]
aya-ebpf = { workspace = true }

[[bin]]
name = "counter-bpf"
path = "src/main.rs"

execve-counter-ebpf/src/main.rs:

#![no_std]
#![no_main]

use aya_ebpf::{
    macros::{map, tracepoint},
    maps::Array,
    programs::TracePointContext,
};

#[map]
static COUNT: Array<u64> = Array::with_max_entries(1, 0);

#[tracepoint(category = "syscalls", name = "sys_enter_execve")]
pub fn on_execve(_ctx: TracePointContext) -> u32 {
    if let Some(ptr) = COUNT.get_ptr_mut(0) {
        unsafe { *ptr += 1 };
    }
    0
}

#[panic_handler]
fn panic(_info: &core::panic::PanicInfo) -> ! {
    unsafe { core::hint::unreachable_unchecked() }
}

That's the whole thing. Let's break it down.

#![no_std] and #![no_main] — there's no standard library in the eBPF runtime. No std::println!, no allocator, no threads. Anything you want has to come from aya_ebpf or core.

The #[map] attribute declares an eBPF map. Maps are the universal communication primitive the kernel side reads and writes them, the userspace side reads and writes them, and the kernel makes sure neither side blows up the other. Our map is a single 64-bit counter Array<u64>

The #[tracepoint(category = "syscalls", name = "sys_enter_execve")] attribute is the interesting bit. It tells aya "this function should run every time the sys_enter_execve tracepoint fires." Tracepoints are stable hook points in the kernel, they don't move between kernel versions the way function symbols do, which makes them ideal for portability.

The function body does the simplest possible thing: grab a pointer to slot 0 of the map, add one. The unsafe block is required because *ptr += 1 is not atomic — two CPUs incrementing at once will lose updates. For a real counter you'd use a PerCpuArray and sum at read time, or use atomic helpers. We are deliberately keeping it minimal. If your dev box does 200 execs/second and we lose three, this post will still work.

The #[panic_handler] is required boilerplate. eBPF programs can't actually panic, the verifier won't let them, but Rust insists you provide a handler. We give it unreachable_unchecked(), which compiles to nothing.

The userspace side

The userspace side has a few jobs. Build the eBPF crate at compile time and embed the result. At runtime, load that bytecode into the kernel, attach the program, and poll the map.

execve-counter/build.rs handles the build-time half:

use anyhow::{anyhow, Context as _};
use aya_build::{Package, Toolchain};

fn main() -> anyhow::Result<()> {
    let metadata = cargo_metadata::MetadataCommand::new()
        .no_deps()
        .exec()
        .context("cargo metadata")?;

    let ebpf = metadata
        .packages
        .into_iter()
        .find(|p| p.name.as_str() == "execve-counter-ebpf")
        .ok_or_else(|| anyhow!("execve-counter-ebpf package not found"))?;

    let root_dir = ebpf
        .manifest_path
        .parent()
        .ok_or_else(|| anyhow!("no parent for {}", ebpf.manifest_path))?;

    let package = Package {
        name: ebpf.name.as_str(),
        root_dir: root_dir.as_str(),
        ..Default::default()
    };

    aya_build::build_ebpf([package], Toolchain::default())?;
    Ok(())
}

cargo_metadata runs cargo metadata for the workspace and gives us back the packages. We grab the one we care about, build an aya_build::Package pointing at its directory, and hand it to aya_build::build_ebpf along with a default toolchain. aya-buil d shells out to nightly cargo with the BPF target and linker, produces an ELF, and drops it in OUT_DIR. We pick it up in main .rs with include_bytes_aligned!.

You'll need build-dependencies for this:

[build-dependencies]
anyhow = { workspace = true }
aya-build = { workspace = true }
cargo_metadata = { workspace = true }

execve-counter/src/main.rs:

use std::time::Duration;

use aya::{maps::Array, programs::TracePoint, Ebpf};
use log::{info, warn};

const EBPF_OBJ: &[u8] =
    aya::include_bytes_aligned!(concat!(env!("OUT_DIR"), "/counter-ebpf"));

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    env_logger::init();
    bump_memlock_rlimit();

    let mut ebpf = Ebpf::load(EBPF_OBJ)?;

    let program: &mut TracePoint = ebpf
        .program_mut("on_execve")
        .ok_or_else(|| anyhow::anyhow!("program not found"))?
        .try_into()?;
    program.load()?;
    program.attach("syscalls", "sys_enter_execve")?;
    info!("attached. counting execve calls — Ctrl+C to stop.");

    let map = Array::<_, u64>::try_from(
        ebpf.map("COUNT").ok_or_else(|| anyhow::anyhow!("map missing"))?,
    )?;

    let mut ticker = tokio::time::interval(Duration::from_secs(1));
    loop {
        tokio::select! {
            _ = ticker.tick() => {
                let n = map.get(&0, 0).unwrap_or(0);
                info!("execve count = {n}");
            }
            _ = tokio::signal::ctrl_c() => {
                info!("shutting down.");
                break;
            }
        }
    }
    Ok(())
}

The shape: Ebpf::load parses the ELF, finds the programs and maps. program_mut("on_execve") grabs our tracepoint by name. load() runs the verifier (this is the moment of truth on real programs — your program either passes or you have a bad day). attach("syscalls", "sys_enter_execve") hooks it up to the tracepoint.

After that, we wrap the COUNT map as an Array<_, u64> and read slot 0 once a second. The actual *ptr += 1 is happening in the kernel on every exec; we're just reading the result.

bump_memlock_rlimit is one of those rite-of-passage details. eBPF maps used to count against the calling process's RLIMIT_MEMLOCK, and the default rlimit is usually 64KB which is nothing. Newer kernels use a different accounting model and this is no longer strictly required, but it's still polite. The function in the repo just calls setrlimit to infinity.

Run it

cargo build --release
sudo RUST_LOG=info ./target/release/execve-counter

You should see:

[INFO  execve_counter] attached. counting execve calls — Ctrl+C to stop.
[INFO  execve_counter] execve count = 0
[INFO  execve_counter] execve count = 0

Now open another terminal and run something. Anything.

ls
cat /etc/hostname
bash -c 'for i in $(seq 1 100); do true; done'

Watch the first terminal:

[INFO  execve_counter] execve count = 4
[INFO  execve_counter] execve count = 5
[INFO  execve_counter] execve count = 107

Hello, kernel.

If you get a "permission denied" or a verifier error on load, you probably aren't root. eBPF needs CAP_BPF (newer kernels) or CAP_SYS_ADMIN. sudo is the easy path.

What we just did

That tiny program is doing something genuinely surprising if you stop and look at it. We compiled a Rust function to a custom bytecode, the kernel verified it terminates and is memory-safe, JITed it to native, and started running it inside the kernel on every execve syscall on the box. We did not load a module. We did not patch a kernel function. We did not even need root in a really privileged sense — CAP_BPF alone gets you here.

Now imagine that instead of incrementing a counter, your tracepoint handler walked the syscall's arguments, decided that this execve was running ps, and rewrote the buffer it would return so that certain PIDs vanished.

That's where we're going. Next post: we hide PIDs from ls /proc by hooking getdents64 and rewriting the directory entries. ps, top, and pgrep all lose their minds. It is very fun.

Until then, the code is here https://github.com/syndrowm/abusing-ebfp. Ping me on Xor LinkedIn if I messed something up, and subscribe if you want Part 2 in your inbox when it drops.

Abusing DNS, Part 7: Who is in charge here?

contact@offensivecontext.com (Evan Anderson) — Thu, 03 Apr 2025 00:00:00 GMT

How does your DNS resolver know how to find the DNS server responsible for resolving your DNS address? Why DNS of course. Pretty simple actually, the DNS client asks the DNS resolver for the address the resolver asks its own DNS resolver who asks the DNS server who to ask for the DNS address.

Ask the DNS server for the DNS address of the DNS server to ask for a DNS address

This is where the NS or Name Server record comes in. The NS record is used to identify the authoritative name server for the domain. AKA who is actually in charge.

For this example let's setup a sub domain of offensivecontext.com so that any request for that sub domain will be forwarded to our DNS server. Lets be very creative with the naming and use sub.offensivecontext.com as our sub domain. Meaning we want any query to *.sub.offensivecontext.com to hit our server.

We need two records to setup this up, a NS record and an A record. For example if I wanted all requests to be forwarded to 1.2.3.4 I would setup the following.

Type	Name	Data
NS	sub.offensivecontext.com	namserver.offensivecontext.com
A	nameserver.offensivecontext.com	1.2.3.4

Visually that would look like this.

Specifics of setting this up is going to depend on your domain registrar, once you have a the above records configured, any of the query types for *.sub.offensivecontext.com will be forwarded to my server at 1.2.3.4.

Wrap up

Getting our system wired into DNS is pretty straight forward, having this setup is going to add some new complications. Next week we will look at adding some more processing in order to deduplicate requests and make the tooling more robust.

Abusing DNS, Part 6: It's all about who you know

contact@offensivecontext.com (Evan Anderson) — Thu, 27 Mar 2025 00:00:00 GMT

One of the benefits we saw for using DNS in Part 1 was the ability to bounce our traffic through different systems that we don't control. Up until now we have been going directly to the DNS server we control.

Talking directly to our server

When your host computers doesn't know how to resolve a DNS address it will ask the DNS resolver it has been configured to use. This resolver is often called a nameserver. That nameserver knows who to ask if it doesn't know the answer and so on until the question gets to your server. What we really want is something like this.

What we really want

Awesome we just need to ask the nameserver So far we have used localhost Okay sooo... we just give the client the nameservers IP...? That is kind of lame, you don't specify an IP in your browser, and dig doesn't take an IP by default. Turns out your system is configured with a nameserver look at the network configuration file and we are good to go right... right

Windows is a special case

Not so fast my dear reader. While finding the configured DNS resolver for most unix systems is relatively straight forward, to have some real fun we are going to be making our client support both linux and windows. Thats right this post is actually about cross platform support and conditional compilation! 😎

Lets take advantage of some more rust features. Thankfully the rust compiler rustc supports multiple platforms and it lets you configure what your code does based on options at compile time.

Linux

Linux and most unixes have been nice enough to standardize on /etc/resolv.conf as a place to find the systems configured resolver. Lets parse resolv.conf and find the name server.

#[cfg(target_os = "linux")]
fn find_dns_resolvers() -> Result<Vec<String>> {
    let mut servers = vec![];

    // Read /etc/resolv.conf to get DNS servers
    if let Ok(content) = std::fs::read_to_string("/etc/resolv.conf") {
        for line in content.lines() {
            let line = line.trim();
            if line.starts_with("nameserver") {
                if let Some(entry) = line.split_whitespace().nth(1) {
                    servers.push(format!("{}:53", entry));
                }
            }
        }
    }
    Ok(servers)
}

find the resolvers for linux

The magic here is the very first line #[cfg(target_os = "linux")] The comThis tells the rust compiler to build this version of find_dns_resolvers when building for linux.

Windows

Now we just need to write the same function for windows ensure the function name and return types are the same and we should be good to go.

#[cfg(target_os = "windows")]
fn find_dns_resolvers(domain: String) -> Result<String> {
    let adapters = ipconfig::get_adapters()?;
    let mut servers = vec![];

    for dns_server in adapters
        .iter()
        .flat_map(|adapter| adapter.dns_servers().iter())
    {
        servers.push(format!("{}:53", dns_server));
    }
    Ok(servers)
}

Here we use the ipconfig crate which makes it very simple to find the DNS server for each of the host systems network adapters. To use ipconfig, we just need to add a conditional dependency to our Cargo.toml and we are all set.

[target.'cfg(windows)'.dependencies]
ipconfig = "0.3.2"

Call it

Finally we need to modify the code to call our new function.

let server = match matches.get_one::<String>("server") {
    Some(s) => s,
    None => {
        let resolvers = find_dns_resolvers()?;
        if resolvers.is_empty() {
            return Err("Unable to find nameserver!".into());
        } else {
            &resolvers[0].to_owned()
        }
    }
};
tracing::debug!("found: {server}");

While verifying the command line arguments instead of having the default DNS server be 127.0.0.1 we will now call out to find_dns_resolvers in order to lookup what the client system is configured to use as a resolver. When you compile this code for linux you get a version of the binary that looks at /etc/resolv.conf and when you compile it for windows you get the version that looks at what is configured for network adapters.

Wrap up

There we have it folks, another one. You may have noticed I didn't cover actually compiling for linux and windows. You can either compile the client on both a linux and a windows machine... or you can do what is called cross compiling (let me know if I should cover cross compiling). Take note, this version will blow up after finding your DNS server but that is okay, next week we will look at how to get DNS traffic to actually route to our DNS server on the internet.

Abusing DNS, Part 5: Client says what?

contact@offensivecontext.com (Evan Anderson) — Thu, 20 Mar 2025 00:00:00 GMT

Now that our client has the ability to read arbitrary data from the server, lets update the client to be able it to send arbitrary data to the sever. (Psssst, if you are new start with Part1)

The problem

As we learned in Part4 DNS can only transfer very small chunks of data mostly from the server to the client. Worse yet there is nothing like a TXT record that lets us send bigger records. There is good news, we can ask the server about any domain name we would like.

Domain names

In DNS the maximum length of a domain is 253 characters. That is a good chunk of data, but there is another limitation. A domain looks something like this www.google.com. Each parts in between the .'s are called labels. Sadly, if we want to get to something works on the wider internet, we don't control all of the labels. For our purposes we are going to use two labels (more on this below). Which leaves us a maximum of 63 characters to work with. There is one more problem but we will talk about that soon.

The answer

Once again we are going to take advantage of being able to ask as many questions as we want, and this time we are also going to take advantage of being able to ask multiple types of questions. To send data we are going to encode our data and chunk it in AAAA record queries until we are done. Once the data is all sent we will send an A record query to let the server know we are done. All the server needs to do is append anything it gets as an AAAA record to the value and when it gets the A query it knows the value is ready.

Wait a minute, we only have 63 bytes of data to work with, how can we send an arbitrary key and value? If we just send AAAA records how will the server know what key to append the value to?

Well, smarty pants, I'm glad you asked. We are going take advantage of labels to make a session. Our DNS requests will be for a domain with two labels that looks like this: {ENCODED_DATA}.{SESSION_ID}

Then all we have to do is encode the key and the value into the data and we are good to go. Thankfully rust's type system and encoding is here to save us.

The answer redux

Okay that was a little hard to write, I have to imagine it is pretty hard to read. To rephrase it we are going to update our strategy as follows.

Client

Pick a random u16 value as our session id
Encode our data and send AAAA queries with a domain made of chunks of data
Send a A query for the session id when we are done

Server

Append all AAAA requests to the session value
An A request means the client is done. Decode the message in the session and save the resulting message under the defined key.

Code updates

Okay up first, lets update the Message structure to have both the key and the value. In src/lib.rs update as follows:

struct Message {
  key: String,
  value: String
}

Structures do stuff

Client Updates

Now on the src/client.rs ... we are going to need to update the CLI parsing to take a new --set value which can parse the KEY and VALUE

...
.arg(
    Arg::new("set")
        .long("set")
        .num_args(2)
        .value_names(["KEY", "VALUE"])
        .help("Set the KEY to VALUE"),
)
.get_matches();
...

argument parsing

client --set SETME "This is the value to set"

now our cli client can do that ^

Have I mentioned that Clap makes parsing arguments pretty easy? Now let's define a new function.

async fn set_value(key: String, value: String){
 todo!()
}

Our new function

The new set_value function will take the key/value that the user wants to set and handle most of the logic to send data. Up first...

let id: u16 = rand::rng().random();
let domain = format!(".{id:x}");

create a session id

Here set_value makes up a random session value and it does that using rand. It will use the hex representation of the session as the domain. Remember the request will look something like {ENCODED_DATA}.{SESSION_ID} .

 let message = Message {
     key: key.to_string(),
     value: value.to_string(),
 };

create our simple message

Then set_value creates a new message with the key/value from the user. Followed by..

let blob = bincode::serialize(&message)?;
let encoded = BASE32_NOPAD.encode(&blob);

serialize/encode the message

Once again rust's ability to serialize and encode the messages to the rescue. In those simple two lines the Message structure is converted to a binary blog and then encoded in DNS domain safe BASE32, perfect for the next step. With the encoded data we can now chunk it up.

Chunk!

Okay not that chunk, we need to break the data up in to blocks of data.

for chunk in encoded.as_bytes().chunks(MAX_LABEL) {
    let chunk = String::from_utf8(chunk.to_vec()).unwrap();
    let fqdn = format!("{}{}", chunk, domain);
    let query = aaaa_query_record(&fqdn)?;
    sock.send_to(&query, server).await?;

chunk it up and send it off

Here set_value converts the encoded ASCII back into bytes with as_bytes, chunks those bytes into fun size pieces ready to send to the server as AAAA records. The chunk size is the MAX_LABEL accounting for the maximum label length of a DNS request.

let query = a_query_record(&format!("{id:x}"))?;
sock.send_to(&query, server).await?;

let the server know the client is done

Finally set_value will send an A query to the server for the just the session id letting the server know that message is done.

Server Updates

fn append_value(key: String, value: String) {
    let mut db = DATABASE
        .get()
        .expect("Database not initialized")
        .lock()
        .expect("Failed to lock database");
    let mut current_value = db.remove(&key).unwrap_or_default();
    current_value.push_str(&value);
    tracing::debug!("{} {}", key.clone(), current_value.clone());
    db.insert(key, current_value);
}

append values

The new append_value function takes a key and value. It appends whatever is passed as value to the value already in the database. Which makes the rest of the changes pretty simple. In our AAAA parser we add:

...
let name = q.qname.to_string().to_uppercase();
let parts: Vec<&str> = name.split(".").collect();
if parts.len() < 2 {
    tracing::debug!("Not enough parts!");
    // TODO: handle some errors
    return Err("That did not work".into());
}

append_value(parts[1].to_string(), parts[0].to_string());
...

This takes the query name, splits it by the . and uses the two values as arguments to the append_value function. Take note that the query looks like this VALUE.KEY and the split is 0 indexed (the only way I don't care what lua says) so part[1] is passed as the key and part[0] is passed as the value.

Now we just need to update parse_a_query

...
let key = q.qname.to_string().to_uppercase();
tracing::info!("new a query: {key}");
let value = get_value(&key).unwrap();

let decoded = BASE32_NOPAD.decode(value.as_bytes())?;
let msg: Message = bincode::deserialize(&decoded)?;

set_value(msg.key.clone().to_uppsercase(), value);
...

The server knows when it receives the A query the client is finished... Which means it can take the session from the query name, decode the data and store the value by the actual key name.

There is one gotcha to call out. You may have noticed when we lookup the query name we uppercase the value. That is because DNS is case insensitive and queries will often be dorked with by the DNS server chains. You may ask for whatthef.example.com but by the time it gets to the example.com servers the messages is something like wHaTTheF.eXamPle.com. That is one of the other reasons we are using BASE32_NOPAD to encode the data.

Have Fun!

That is it. We can now send arbitrary key/value data to the DNS server and retrieve it with the client! As with the other parts run cargo run --bin server in one terminal and we can have fun with the client in another terminal.

Now in the client run

# set the value
cargo run -q --bin client -- --set SUBSCRIBE "See protocols can be a lot of fun."

# get the value
cargo run -q --bin client -- --get SUBSCRIBE

Thanks for reading. If you are enjoying this please share, subscribe, yell, scream laugh. And of course I'm on bluesky and linkedin.

In the next installment we will finally set this thing up on the internet and get recursive queries happening. See you then.

Abusing DNS, Part 4: Let the fun begin?

contact@offensivecontext.com (Evan Anderson) — Thu, 13 Mar 2025 00:00:00 GMT

Hello again friends. This is exciting we are starting to actually get somewhere.... Let's get after it, first a quick recap. Remember we are building a key/value store with DNS as our communication mechanism to explore how hackers get data out of networks. Part 1 was an intro to the concepts we are going to use, Part 2 we built a basic server, Part 3 we built a simple client. Oh and the code is here.

For this post we are going to transfer data. This might sound pretty easy as DNS is designed to answer questions with data... Not so fast, DNS is designed to answer questions, short questions and the original DNS RFC (883) is from 1983 not a lot of data back then. Which technically makes DNS a millennial.

Data was different back then

Getting Data

This is part relatively easy. DNS has a very handy TXT record (hey the client we built was asking for those records?!?!). Sadly there are some limitations most notably, you can only return text annnd you are limited to 255 characters segments. What if I wanted to get the contents of /etc/passwd for... reasons. I don't have to tell you that 255 characters is not a lot of room. Thankfully we have roughly unlimited times to ask.

There are a few ways to accomplish this, for this example we will us an A request tell the DNS server what TXT record we are going to query and then query that TXT record repeatedly until we have all the data.

Server changes

First we need a database to store the key we are going to be looking for. Here we are using the OnceLock struct to make a global Mutex locked HashMap. Which is a really fancy way to store a key and a value in a memory and thread safe way.

type Database = HashMap<String, String>;

static DATABASE: OnceLock<Mutex<Database>> = OnceLock::new();

fn get_value(key: &String) -> Option<String> {
    let mut db = DATABASE
        .get()
        .expect("Database not initialized")
        .lock()
        .expect("Failed to lock database");
    db.remove(key)
}

fn set_value(key: String, value: String) {
    let mut db = DATABASE
        .get()
        .expect("Database not initialized")
        .lock()
        .expect("Failed to lock database");
    db.insert(key, value);
}

Theset_value function does what you would expect (set a value). The get_value function retrieves a value and removes it from the database, you will see why in a second.

Then all we have to do is make sure we initialize the database in main.

DATABASE.get_or_init(|| Mutex::new(HashMap::new()));

Next we will parse the A query and add the request value to the database.

First in a new file src/lib.rs we created a new structure that we will use to pass the message. This is overkill for the example but will make more sense in later parts of this series.

use serde::{Deserialize, Serialize};

#[derive(Debug, Serialize, Deserialize)]
pub struct Message {
    pub value: String,
}

Next we define a function to parse the A record.

async fn parse_a_query(q: Question<'_>) -> Result<ResourceRecord<'_>> {
    let name = q.qname.to_string().to_uppercase();
    tracing::info!("new a query: {name}");

    let value = fs::read_to_string("/etc/passwd").await?;
    let data = bincode::serialize(&Message { value })?;
    let encoded = BASE32_NOPAD.encode(&data);

    set_value(name.clone(), encoded);

    tracing::info!("Set value {}", name);
    Ok(ResourceRecord::new(
        q.qname,
        CLASS::IN,
        2,
        RData::A(A {
            address: u32::from_be_bytes([41, 41, 41, 41]),
        }),
    ))
}

parse_a_query starts out by pulling the name out of the record. Next it reads in the data the client will be requesting, in this case /etc/passwd. Then we start to see some real magic, serializing the buffer into something we can pass to the client. Step 1 of serializing is utilizing bincode to turn our structure into bytes, then it uses data_encoding to turn those bytes into ASCII which is safe to transfer. After encoding the value it uses set_value to store the value with name as the key. This encoding step is also a little overkill for this example and will come in handy in later versions of the code. Finally set_value responds with a generic A record so the client knows the server was successful.

Now we need to handle the TXT queries:

async fn parse_txt_query(q: Question<'_>) -> Result<ResourceRecord<'_>> {
    let name = q.qname.to_string().to_uppercase();
    tracing::info!("Lookup {}", name);

    let value = get_value(&name).unwrap_or("AAAA".to_string());

    let len = value.clone().len().min(255);
    let (txt, remainder) = value.split_at(len);

    tracing::info!("Got value {}", value);

    if !remainder.is_empty() {
        set_value(name.clone(), remainder.to_string());
    } else {
        tracing::info!("No remaining info");
    };

    tracing::info!("returning {}", &value);

    let mut data = TXT::new();
    data.add_char_string(txt.to_string().try_into()?);
    Ok(ResourceRecord::new(
        q.qname.clone(),
        CLASS::IN,
        2,
        RData::TXT(data),
    ))
}

The parse_txt_query function uses get_value to lookup the value based on the name value from the query. It then uses split_at to chunk up the data into 255 byte values. It then stores the remainder back in the database for the next time the client queries. (Thus the delete in get_value). Finally this chunk of the data is returned as a response to the TXT request.

Client updates

With our server updated, now the client needs to know what to do. First the client will make an A query with the name of the key we want from the database. Then it will make TXT queries until it has all of the data.

fn a_query_record(domain: &str) -> Result<Vec<u8>> {
    let mut pkt = Packet::new_query(1);
    let q = Question::new(
        Name::new_unchecked(domain),
        TYPE::A.into(),
        CLASS::IN.into(),
        false,
    );
    pkt.set_flags(PacketFlag::RECURSION_DESIRED);
    pkt.questions.push(q);
    Ok(pkt.build_bytes_vec()?)
}

a_query_record should look familiar, it is basically txt_query_record but for A's.

fn parse_txt_response(data: Vec<u8>) -> Result<String> {
    let mut rv = String::new();
    let packet = Packet::parse(&data)?;
    let answer = packet.answers[0].clone();
    if let RData::TXT(val) = answer.rdata {
        for (k, _) in val.attributes() {
            rv += &k;
        }
    }
    Ok(rv)
}

parse_txt_response takes a buffer, parses it into a packet and extracts the relevant data from the answers attributes. Finally it returns the value as a String.

let query = a_query_record(domain)?;

let mut buf = [0; 4096];
let (_size, _) = sock.recv_from(&mut buf).await?;
// let data = buf[..size].to_vec();

// TODO: How bout you check for some errors?
// let packet = Packet::parse(&data)?;

First the client makes the A query. Notably here is a good chance to check for errors, I have skipped that as this post is already getting pretty long.


let query = txt_query_record(domain)?;
let mut incoming = String::new();
loop {
    sock.send_to(&query, server).await?;
    let mut buf = [0; 4096];
    let (size, _) = sock.recv_from(&mut buf).await?;
    let data = buf[..size].to_vec();
    let data = parse_txt_response(data)?;
    incoming += &data;
    if data.len() < 255 {
        break;
    }
}

let decoded = BASE32_NOPAD.decode(incoming.as_bytes())?;
let message: Message = bincode::deserialize(&decoded)?;
tracing::info!("value:\n{}", message.value);

Now for the magic on the client side. First we create a txt_query for our magic domain. Then drop into a loop and make the same txt request until we get back a buffer that didn't use the whole 255 bytes.

Then it is just a matter of running the serialization steps the server took, but in reverse. BASE32_NOPAD decode the data and bincode::deserialize.

Run it!

It is finally that point. Run the server in one terminal and the client in another and watch the magic happen.

Phew that was a lot. Congrats for making it this far. If you made it this far make sure you subscribe, come yell at my on bluesky or linkedin. Next week, we will update the client to send data to our dns-kv server.

Brain explode: AI is getting a little scary

contact@offensivecontext.com (Evan Anderson) — Mon, 10 Mar 2025 00:00:00 GMT

Okay I kind of just had my mind blown.

I am working on an interesting project in which I need to modify a PE file. The problem with modifying PE files is there is a checksum that windows defender looks at and flags you as being a mean bad jerk and puts your executable in executable jail. Soooo I need to fix that header.

First I asked chatGPT how I could accomplish this with rust.

Looks plausible. I copy the code into a new rust project... well the code was close, but chatGPT made up some functions and thus the logic of the code won't work.

A little frustrated I asked google how to check the header with python...

Cool, Google AI gave me a snippet... I made a quick virtualenv, pip installed pefile and I had a working example that could validate the header checksum for me.

Next I loaded up cursor and pointed it at the rust project I had made from chatGPT. Not even thinking about the python snippet and venv in that folder. (This is called foreshadowing, It is my understanding that it is good for story telling)

I ask the cursor agent (which is claude-sonnet 3.7) the following:

Cursor did it's thing. Offered up some changes and it works.

x-pe$ cargo run
   Compiling x-pe v0.1.0 (/home/evan/repos/x-pe)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.37s
     Running `target/debug/x-pe`
Old Checksum: 0x692460
New Checksum: 0x683B86
Checksum fixed successfully!

Looking at what cursor did. First it searched for the library and functions to fix the header. Didn't find anything... It also recognized that the library functions from the chatGPT code didn't exist. Then with no prompting at all found the python snippet, the algorithm in the virtualenv code and re-implemented the algorithm in rust... 🤯

And it worked the first time I ran it. Most importantly now defender doesn't hate my binaries.

I don't know what it means exactly, but that was pretty cool.

Abusing DNS, Part 3: What do you want?

contact@offensivecontext.com (Evan Anderson) — Thu, 06 Mar 2025 00:00:00 GMT

Now that we have a server, it is time to build the client. In Part 2 we laid out the ground work of our project and built a server that could respond to various DNS queries (check out Part 1 if that is gobbledygook). As usual you can jump right to the source code on github TODO.

As a recap here is where we left our client:

dns-kv$ cargo run --bin client
   Compiling dns-kv v0.1.0 (/home/evan/dns-kv)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.24s
     Running `target/debug/client`
Hello, world!

Let's fix that and make a command line tool that is able to talk to our new DNS server and ask it for a TXT record. Sounds like fun doesn't it?

First we are going to need another library that will assist us in parsing out command line argument (clap). Clap is awesome and helps us with most the things we need to make a fancy CLI app. Sound good? Right about now you are probably asking...

How do I get the clap?

What did you just say?

Lucky for us rust, more specifically cargo makes that very simple for us. From your project folder run the following command and you are good to go.

dns-kv$ cargo add clap -F cargo
    Updating crates.io index
      Adding clap v4.5.31 to dependencies
             Features:
             + cargo
             + color
...
    Updating crates.io index
     Locking 13 packages to latest compatible versions
      Adding anstream v0.6.18
...
dns-kv$

That is it, now we have a very powerful tool to enable us to create CLI applications. For this example we are going to use the builder pattern.

Parse away

Just like dig or nslookup our CLI is going to need to know what domain we are looking up and what server to talk to... Let's parse some arguments.

let matches = command!() // requires `cargo` feature
  .arg(arg!([server] "DNS Server").default_value("127.0.0.1:5353"))
  .arg(arg!(-g --get <NAME> "Get the domain").required(true))
  .get_matches();

let domain = matches
  .get_one::<String>("get").expect("domain is required");

let server = matches
  .get_one::<String>("server").expect("server has default");

Cool, what does that do? First we use the command macro to create our Command struct we then add our arguments. server which is the DNS server to query and will default to 127.0.0.1:5353 which is perfect as that is where our server currently is. Next we add the argument for the domain we would like to get which for now is required ... you know what let me just show you.

dns-kv$ cargo run --bin client -- -h
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.05s
     Running `target/debug/client -h`
Usage: client --get <NAME> [server]

Arguments:
  [server]  DNS Server to query [default: 127.0.0.1:5353]

Options:
  -g, --get <NAME>  Get the domain
  -h, --help        Print help
  -V, --version     Print version

Oh that is right, one of the great things about having clap in your project is you get built in help. Okay thats enough of that I promise.

What do you want?

Now the CLI knows the domain and server we would like to talk to, it just has to ask. For now the CLI will assume we would like a TXT record.

fn txt_query_record(domain: &str) -> Result<Vec<u8>> {
    let mut pkt = Packet::new_query(1);
    let q = Question::new(
        Name::new_unchecked(domain),
        TYPE::TXT.into(),
        CLASS::IN.into(),
        false,
    );
    pkt.set_flags(PacketFlag::RECURSION_DESIRED);
    pkt.questions.push(q);
    Ok(pkt.build_bytes_vec()?)
}

The txt_query_record creates a DNS query packet that is asking for a TXT record for the domain we specified.

    let query = txt_query_record(domain)?;

    let sock = UdpSocket::bind("0.0.0.0:0").await?;
    sock.send_to(&query, server).await?;

    let mut buf = [0; 4096];
    let (size, _) = sock.recv_from(&mut buf).await?;
    let data = buf[..size].to_vec();

With that query in hand the CLI binds to an open UDP port 0.0.0.0:0 let's the kernel pick the port we will send data from. Sends the query packet to the server and reads the response.

let packet = Packet::parse(&data)?;
tracing::info!("{:#?}", packet.answers);

Finally the cli parses the response from the packet and prints out the response.

dns-kv$ cargo run --bin client -- -g domain.com
   Compiling dns-kv v0.1.0 (/home/evan/repos/dns-kv)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 2.59s
     Running `target/debug/client -g domain.com`
2025-03-05T22:19:50.479792Z  INFO client: [
    ResourceRecord {
        name: Name(
            "domain.com",
            "12",
        ),
        class: IN,
        ttl: 2,
        rdata: TXT(
            TXT {
                strings: [
                    CharacterString {
                        data: "AAAA",
                    },
                ],
                size: 5,
            },
        ),
        cache_flush: false,
    },

Lets go

Well that is coming along nicely if I don't say so myself. If you made it this far, you might was well click that subscribe button over there. Come yell at my on bluesky or linkedin. Next week, we will start turning dns-kv into a tool that will let us transfer data.

Abusing DNS, Part 2: Serving up some fun

contact@offensivecontext.com (Evan Anderson) — Thu, 27 Feb 2025 00:00:00 GMT

As we continue to explore how hackers take advantage of DNS, our goal for part 2 is to get into some rust code and build a server that has enough functionality that it will be able to respond to simple DNS requests. If you missed it, check out Part 1 for an overview and refresher on the protocol. Follow along or jump to the source code here.

Let's write a server!

I'm going to assume you have rust installed. Up first let's create our project and add some dependencies.

$ cargo new dns-kv && cd dns-kv
$ cargo add tokio -F full
$ cargo add simple-dns
$ cargo add tracing, tracing-subscriber, bincode, data-encoding
$ cargo add tracing
$ cargo add tracing-encoding
$ cargo add tracing-subscriber
$ cargo add bincode
$ cargo add data-encoding
$ cargo run
...
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.04s
     Running `target/debug/dns-kv`
Hello, world!

💡 I cut a bunch of fluff out of the above, don't be worried if you see a bunch of stuff in your shell.

And a client!?!?!

Just kidding, Part 3 will be devoted to the client. For now though, lets setup our project so that we can have a server and a client.

dns-kv$ mkdir src/bin
dns-kv$ mv src/main src/bin/server.rs
dns-kv$ cp src/bin/server.rs src/bin/client.rs

Now we have two binaries in our project. You run them like this.

dns-kv$ cargo run --bin server
   Compiling dns-kv v0.1.0 (/home/evan/dns-kv)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.25s
     Running `target/debug/server`
Hello, world!
dns-kv$ cargo run --bin client
   Compiling dns-kv v0.1.0 (/home/evan/dns-kv)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.24s
     Running `target/debug/client`
Hello, world!

For real lets write a server

Rust forces you to think about errors and error handling from the start. If your rust code is confusing or painful... You aren't doing errors right. Luckily we can start off pretty simple and handle more complicated errors as we run into trouble.

// Easy mode error handling.
type Result<T> = core::result::Result<T, Error>;
type Error = Box<dyn std::error::Error>;

This is one of the best videos on rust error handling I've found.

Now you can update your main function in src/bin/server.rs with the following.

#[tokio::main]
async fn main() -> Result<()> {
    // everybody love logging
    use tracing_subscriber::{fmt, prelude::*, EnvFilter};
    tracing_subscriber::registry()
        .with(fmt::layer())
        .with(EnvFilter::new(std::env::var("RUST_LOG").unwrap_or_else(
            |_| format!("{}=debug", env!("CARGO_CRATE_NAME")),
        )))
        .try_init()?;

    // create teh server socket and listen on 5353
    let socket = UdpSocket::bind("0.0.0.0:5353").await?;
    tracing::info!("listening on {}", socket.local_addr().unwrap());

    let socket = std::sync::Arc::new(socket);
    let mut buf = vec![0u8; 2048]; // max dns packet is 512

    loop {
        let socket = socket.clone();
        let (size, peer) = socket.recv_from(&mut buf).await?;
        let data = buf[..size].to_vec();
        // Spawn a new task for each incoming datagram
        tokio::spawn(async move {
            tracing::debug!("received {} bytes from {}", size, peer);
            let rv = handle_dns_query(socket, data, peer).await;
            if let Err(e) = rv {
                tracing::debug!("{e:?}");
            }
        });
    }
}

Let's break that down. #[tokio::main] is a macro from the asynchronous tokio project. That is right, we are using async code so our server will be blazingly fast.

Our main function returns Result<()> this magic can happen because we defined above.

Next up we setup tracing. Because everybody loves logging.

Finally in the loop we listen for connections and spawn tasks to read from the socket and handle the requests in handle_dns_query.

Handling the request

Let's take a look at handle_dns_query

async fn handle_dns_query(socket: Arc<UdpSocket>, data: Vec<u8>, peer: SocketAddr) -> Result<()> {
    let packet = Packet::parse(&data)?;

    let mut response = packet.clone().into_reply();

    for q in packet.questions {
        let answer = match q.qtype {
            QTYPE::TYPE(TYPE::A) => Ok(parse_a_query(q).await?),
            QTYPE::TYPE(TYPE::AAAA) => Ok(parse_aaaa_query(q).await?),
            QTYPE::TYPE(TYPE::TXT) => Ok(parse_txt_query(q).await?),
            _ => Err("invalid type"),
        }?;

        response.answers.push(answer);
    }

    let rd = response.build_bytes_vec()?;
    socket.send_to(&rd, peer).await?;

    Ok(())
}

This function takes a copy of the UDPSocket, the data to process and information about the peer aka who made the request. It then parses the data into a DNS packet and prepares a response. Next it iterates over the questions in the packet and hands them off to a function that handles the specific response.

Let's look at the first query handler parse_a_query

async fn parse_a_query(q: Question<'_>) -> Result<ResourceRecord<'_>> {
    Ok(ResourceRecord::new(
        q.qname,
        CLASS::IN,
        2,
        RData::A(A {
            address: u32::from_be_bytes([41, 41, 41, 41]),
        }),
    ))
}

Like the name implies, this function is handling an A query. For now it isn't doing much, just responding with a static response. As saw last week and IP address is just a funky way of encoding a number.

For fun, this is what that conversion looks like in python.

>>> socket.inet_ntoa(struct.pack('>BBBB', 41,41,41,41))
'41.41.41.41'

Wrap it up

We are in the home stretch, lets run the server and test it out with dig. In one shell run the server.

dns-kv$ cargo run --bin server

And in another shell test it out.

dns-kv$ dig +short @127.0.0.1 -p 5353 A test.com
41.41.41.41
dns-kv$ dig +short @127.0.0.1 -p 5353 AAAA test.com
::41.41.41.41
dns-kv$ dig +short @127.0.0.1 -p 5353 TXT test.com
"AAAA"

Amazing! We've done it. In the first command we use dig to ask our server on 127.0.0.1 port 5353 what the A record is for test.com and as we expected, we get back 41.41.41.41. We then do the same to check that the AAAA and TXT records are working as we expect.

Call to action

Check out Part 1 to see where this all started, subscribe if you want to see more, follow me up on the butterfly site if you want some more memes or to make fun of my non-sense. See you next week in Part 3 where we will be building the CLI client with clap.

Abusing DNS, Part 1: How does DNS do what it do?

contact@offensivecontext.com (Evan Anderson) — Thu, 20 Feb 2025 00:00:00 GMT

DNS is one of the protocols that make the internet possible. In many ways DNS is the phone book of the internet. DNS turns the domain you are trying to get to into the IP address your computer needs to get there. DNS is robust network of inter connected systems used to translate human readable domains into the IP address, but it can be much more.

In this series we will use rust to build a key-value store that uses DNS to transfer data between our custom DNS server and client. Future code will be available on Github.

Let's start by looking at the protocol, we will then build a simple DNS server/client application and finally take advantage of what we know to build a key value store.

DNS requests, how do they work?

Clown doesn't know how DNS do

It is important to know that computers don't think in strings like people (www.google.com) they think in binary 10001110111110100100100000100100. Humans are really bad at thinking in binary so we make computers to backflips to manage all of that for us.

$ dig +short @1.1.1.1 www.google.com
142.250.69.228

Astute readers like yourself probably notice that isn't binary. We humans are so bad at binary we have computers encode the numbers (we wont remember) into more human readable forms, thus 142.250.69.228.

>>> socket.gethostbyname('www.google.com')
>>> socket.inet_aton('142.250.69.228')
b'\x8e\xfaE\xe4'
>>> struct.unpack('>I', b'\x8e\xfaE\xe4')
(2398767140,)
>>> bin(2398767140)
'0b10001110111110100100100000100100'

We will utilize data encodings to our advantage later in this series. Back to DNS...

What is happening when you make a DNS request?

$ dig www.google.com

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5248
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.google.com.                        IN      A

;; ANSWER SECTION:
www.google.com.         300     IN      A       142.250.72.36

;; Query time: 28 msec
;; SERVER: 192.168.0.1#53(192.168.0.1) (UDP)
;; WHEN: Thu Feb 20 09:10:07 MST 2025
;; MSG SIZE  rcvd: 59

The above dig command asked "what is the IPv4 address for www.google.com".

While a very simple command on its face, a very complex set of things just happened.

First my system looked at it's local resolver settings and found 192.168.0.1 as my local DNS server. Next a UDP request with an A question was sent to 192.168.0.1. From here the server checked to see if it knew an IP for www.google.com and if that IP address was still valid by checking the TTL. If 192.168.0.1 did not know the answer it then looked for it's own resolver and sent a request asking the same question. I'm simplifying here, but that continues until we get an answer or don't have any other server to ask. Finally the answers are sent all the way back and my system has the IP.

Well that is pretty cool. We ask a server we don't control to send requests for us and get responses from our own servers... Wait, what else can we ask for?

Glad you asked! There are many different questions you can ask. The server responds with records. We already saw the most common A query which will return an A record. The A query is so common, in fact, dig assumes that is what you meant. If you want to be more explicit you can specify the record type. Let's look at a few different query types.

Later in the series we will be going further into query and record types, for now, know that there are multiple record types that contain different data types. A records are IPv4, AAAA (quad A) records contain IPv6 addresses. TXT records have text data. MX (Mail Exchanger) have the mail server. These are the most common, there are a whole bunch (go read the wiki pages and donate to wiki foundation while you are there).

That is it for now. Up next we will start our rust project and build a UDP DNS server that can respond to various query types with our own DNS records.

Subscribe, follow, etc if you want to see more.

Spooky simple Python tricks

contact@offensivecontext.com (Evan Anderson) — Mon, 21 Oct 2024 00:00:00 GMT

In infosec, being able to explore and manipulate data is a super power. After years (decades) of using python, these are some of the things I lean on almost every day to make the hax and explore.

Python is an amazing programming language. Python is simple, concise and flexible. It is especially useful to quickly solve real problems. There is a reason that Python is the language of ML and AI and data sciences.

Here are some beginner python tricks to quickly format data, encode/decode various data types, and quickly automate exploring CISA KEV list.

REPL

For starters, interactivity is key for exploring data and quickly iterating on ideas. The Python REPL makes exploring and playing with data a breeze.

With Python installed on most systems using the REPL is as simple as typing python into your terminal.

$ python3
Python 3.11.8 (main, Feb 13 2024, 09:03:56) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

Once in the REPL you are executing python. Just type the python and hit enter. It couldn't be more simple

>>> 1+1
2
>>> print("hello world")
hello world

HELP!

Don't worry Python is here to help. The help() function will show you documentation and be a useful reminder if you forget any of the syntax.

>>> help()
Welcome to Python 3.11's help utility! If this is your first time using
Python, you should definitely check out the tutorial at
https://docs.python.org/3.11/tutorial/.

Enter the name of any module, keyword, or topic to get help on writing
Python programs and using Python modules.  To get a list of available
modules, keywords, symbols, or topics, enter "modules", "keywords",
"symbols", or "topics".

Virtual environments

You will likely need to install some additional packages that can make your life easier. Don't over think this we are hacking and exploring data. VirtualEnvs are a perfect solution for experimenting and quickly installing packages in a partially isolated environment.

python3 -m venv venv
source venv/bin/activate
pip install --upgrade pip
pip install requests rich

Pretty Printing

If you are going to be looking at data in the shell... you need to make the output pretty. Thankfully we have the amazing rich library. Rich has many features to make your script output beautiful. Luckily for us rich has the pretty module. Once installed in the REPL Python data structures will automatically be pretty printed with syntax highlighting.

>>> from rich import pretty
>>> pretty.install()
>>> x = {'a': 1, 'b': 2}
{'a': 1, 'b': 2}

HTTP Client

The world runs on HTTP. Being able to make quick simple HTTP requests and parse the data is its own super power. Maybe you would like to explore the CISA Known Exploited Vulnerabilities (KEV) list.

The python requests module is designed to make simple HTTP requests well... simple. The requests tag line is Built for human beings.

Here we make an HTTP request to download the CISA KEV list and parse the response as JSON with the .json() call. In Python JSON is translated to the built-in dictionary data type. For our purposes a dictionary is a set of key: value pairs. The .keys() method on a dictionary shows us the top level keys. We then get the values for the title and dateReleased keys.

>>> import requests
>>> r = requests.get(
 "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"
 ).json()
>>> r.keys()
dict_keys(['title', 'catalogVersion', 'dateReleased', 'count', 'vulnerabilities'])
>>> r['title'], r['dateReleased']
('CISA Catalog of Known Exploited Vulnerabilities', '2024-03-18T17:37:00.9876Z')

>>> r['vulnerabilities'][-1]
{
    'cveID': 'CVE-2024-27198',
    'vendorProject': 'JetBrains',
    'product': 'TeamCity',
    'vulnerabilityName': 'JetBrains TeamCity Authentication Bypass Vulnerability',
    'dateAdded': '2024-03-07',
    'shortDescription': 'JetBrains TeamCity contains an authentication bypass vulnerability that allows an attacker to perform admin actions.',
    'requiredAction': 'Apply mitigations per vendor instructions or discontinue use of the product if mitigations are unavailable.',
    'dueDate': '2024-03-28',
    'knownRansomwareCampaignUse': 'Unknown',
    'notes': 'https://www.jetbrains.com/help/teamcity/teamcity-2023-11-4-release-notes.html'
}

Finally lets build a list of all of the CVEs on the CISA KEV list, get a count of how many cves we found and look at the first 5 entries to sanity check.

>>> cves = [i['cveID'] for i in r['vulnerabilities']]
>>> len(cves)
1089
>>> cves[0:5]
['CVE-2021-27104', 'CVE-2021-27102', 'CVE-2021-27101', 'CVE-2021-27103', 'CVE-2021-21017']

Encoding and decoding data

Data can be represented in many ways and thus comes in all shapes and sizes. Being able to convert between data types is essential for your new super power. Let's look at the very basics.

[WARNING] encoding is not encryption

"bWFuaXB1bGF0aW5nIGRhdGEgaXMga2V5"

"6d616e6970756c6174696e672064617461206973206b6579"

[
    '0b1101101', '0b1100001', '0b1101110', '0b1101001', '0b1110000', '0b1110101',
    '0b1101100', '0b1100001', '0b1110100', '0b1101001', '0b1101110', '0b1100111',
    '0b100000', '0b1100100', '0b1100001', '0b1110100', '0b1100001', '0b100000',
    '0b1101001', '0b1110011', '0b100000', '0b1101011', '0b1100101', '0b1111001'
]

base64

base64 is one of the most common schemes allowing you to encode binary data into printable characters. Base64 is so common it is built into the Python standard library, the docs are here.

Lets take a base64 value and convert it to binary and then back to base64. Take note in Python the underscore _ is used to represent the output from the previous line. This is super useful if you forget to assign the output of your command.

>>> from base64 import b64encode, b64decode
>>> x = "bWFuaXB1bGF0aW5nIGRhdGEgaXMga2V5"
>>> b64decode(x)
b'manipulating data is key'
>>> b64encode(_)
b'bWFuaXB1bGF0aW5nIGRhdGEgaXMga2V5'

hex

Another way to represent binary data as printable characters is hexidecimal. This type of representation is often seen used in tools like hexdump

Here is how you can convert from a hexidecimal encoding to binary and back.

>>> from binascii import hexlify, unhexlify
>>> unhexlify("6d616e6970756c6174696e672064617461206973206b6579")
b'manipulating data is key'
>>> hexlify(_)
b'6d616e6970756c6174696e672064617461206973206b6579'

binary

With all this talk of binary, lets look at how you can use a list comprehension to see what the world in binary.

First we create a list of binary values called x. On the next line we convert each item in the list to an integer with the call to int() and convert that integer into a character with the char() function. Finally we join all the characters into a single string.

>>> x = [
...     '0b1101101', '0b1100001', '0b1101110', '0b1101001', '0b1110000', '0b1110101',
...     '0b1101100', '0b1100001', '0b1110100', '0b1101001', '0b1101110', '0b1100111',
...     '0b100000', '0b1100100', '0b1100001', '0b1110100', '0b1100001', '0b100000',
...     '0b1101001', '0b1110011', '0b100000', '0b1101011', '0b1100101', '0b1111001'
... ]
>>> ''.join([chr(int(i, 2)) for i in x])
'manipulating data is key'
>>> [bin(ord(i)) for i in _]
>>>  ['0b1101101', '0b1100001', '0b1101110', '0b1101001', '0b1110000', '0b1110101',
     '0b1101100', '0b1100001', '0b1110100', '0b1101001', '0b1101110', '0b1100111',
     '0b100000', '0b1100100', '0b1100001', '0b1110100', '0b1100001', '0b100000',
     '0b1101001', '0b1110011', '0b100000', '0b1101011', '0b1100101', '0b1111001']

Data Objects

As we saw earlier a simple way to interact with JSON objects in Python is to convert them to the dictionary data structure. What if you want to save the dictionary locally instead of reading it from a HTTP request?

json

Here we save or dump a Python dictionary as a JSON string into the file example.json and then read or load that same JSON string from a file converting it back to a dictionary.

The magic here is the call to the open() function which creates a readable stream the json module can then use to write or read the file contents.

>>> import json
>>> json.dump({'a': 1, 'b': 2}, open('example.json', 'w'))
>>> json.load(open('example.json'))
{'a': 1, 'b': 2}

yaml

Yet another markup language is YAML. As it is designed to be human readable YAML is often used for configuration files and is the defacto language of DevOps. Thanks to the PyYaml Framework it is easy convert YAML to Python dictionaries and store the objects as files.

First we need to install the PyYaml module into the virtualenv

pip install pyyaml

Once installed we can interact with YAML pretty much the exact same syntax as the json module.

>>> import yaml
>>> yaml.dump({'a': 1, 'b': 2}, open('example.yaml', 'w'))
>>> yaml.safe_load(open('example.yaml'))
{'a': 1, 'b': 2}