Cybersecurity Ops with bash: Attack, Defend, and Analyze from the Command Line

Welcome back to the deep dive. We're your shortcut to getting well, incredibly well informed without feeling totally overwhelmed.

Yeah, there's a lot out there.

There really is. So today we're diving into something powerful, maybe a bit underestimated, a kind of secret weapon that's actually been part of computing for decades. Foundational really exactly, but it's becoming super critical now in cybersecurity. Okay, let's unpack this. We are talking about cybersecurity operations, but maybe not with the fancy, expensive tools you might think of. First, we're talking about the command line.

Ah, yes, good old command line, specifically the Bash Shehell.

Our guide for this is a really practical book, Cybersecurity Ops with Bash, Attack, Defend and Analyze from the command Line by Paul Truncone and Carl Alvin. Great resource, totally, and our mission today is to give you a shortcut a way to see how Bash isn't just you know, for developers coding away or cised men's managing servers. It's this incredibly flexible multi tool anyone interested in computer security, whether you're on the offense probing systems or on defense

And what's truly fascinating here, I think is just how fundamental the command line is. I mean, most of us, right, we spend our time clicking around in graphical interfaces. Guisappoint click and they're great, super easy to use, no doubt, but that ease it often costs you something speed, maybe flexibility, and you definitely get distanced from what the system is actually doing.

Underneath, like a layer of abstraction exactly.

GUIs are like that nice dashboard in your car. Looks good, tells you the basics, but the command line that's like lifting the hood. You're right there with the engine.

Okay. I like that analogy, and this.

Deep dive hopefully will kind of reconnect you to that raw power, show you that Bash is this direct, super efficient way to tap into everything your operating system can do.

Getting under the hood. I like, yeah, So, okay, why Bash specifically for cybersecurity? It still feels a bit basic.

Well, it's basic in the best sense, you know, it's foundational. It's universal. Bash started in the Unix and Linux world obviously, but it's just everywhere now. It's standard on macOS, and you can get it really easily on Windows is get Bash seguine or the Window subsystem for Linux WSL WSL. Yeah, which means the stuff we talk about today. These aren't

Happened on one. Okay, So it's like the ultimate cross platform utility belt for security folks pretty much. But to really use that belt effectively, especially for tricky security tasks, we probably need to nail down some and core ideas first. What are the essential bits of Bash that make it so good for this?

Yeah, definitely if we connect this to the bigger picture, the real power often comes from how Bash handles data, how it moves information around data streams exactly. Every program fundamentally has like three channels, one for input coming in stin, one for normal output going out strout, and one for error messages.

Sure, okay, in out and oops.

Yeah basically. But the magic and where Bash really shines for security work is redirection and piping.

Right.

This is what lets you chain simple commands together to build surprisingly powerful custom tools like right on the spot.

So redirection is sending stuff places.

Yep. You can send the normal output of a command straight into a file maybe command results dot out, or if you want to add to a file that's already there, you use up and it tended exactly and you can send just the error messages somewhere else. Maybe two aero loog dot txt, or combine both normal output and errors into one file with evan in handy, or just make output disappear entirely if you don't need it, send it

Right, see it and save it makes sense. And piping that's the connector right the symbol. That's the one.

Piping takes the standard output from the command on the left and feeds it directly as the standard input to the command on the.

Right, connecting the tools precisely.

This is how you build those complex workflows from simple building blocks. It's like creating an assembly line for your data right there in the terminal okay, And one more thing. If you have a command that might take a while, like maybe pinging a machine constantly to see if it's up, you can run it in the background using the ampersand so like ping one two point one sixty eight point

Oh that's useful.

Yeah, And you can check on those background tasks with the jobs command and bring one back to the foreground with FG if you need to interact with it.

Got it.

And beyond just moving data, remember Bash is a full on programming language too. You've got variables, you can read input, you have if statements, wild loops, functions, you can automate almost anything.

That flexibility is huge. Okay, but here's something you mentioned in the book that seems to trip people up a lot. Honestly, it confused me at first too.

Ah, let me guess shell patterns versus regular expressions.

Bingo. It gets really interesting here. What's the fundamental difference and why is getting them mixed up such a potential problem in security?

It's a great question, and yeah, it is critical for doing things accurately. So shell patterns think for match anything, for match any single character for a range like a ZA right the file globbing stuff exactly. They're primarily designed for matching filenames in the filesystem. When you type ls dot log, you're telling the shell itself to find all filenames ending in dot log.

Okay, so it's about the names of files, correct.

Now. Regular expressions or rejects are different beasts, which more powerful patterns designed for matching text content stuff inside files or within a stream of data.

Like searching inside a log file.

Precisely. Rejects has a much richer, sometimes more complex set of special characters and rules. And you use rejects with tools that process text like rep or AUC or said.

So, different tools, different patterns, yeah.

And confusing them. That can lead to you missing crucial evidence because you used a file name pattern to search file content, or maybe doing something unintended because your pattern match files you didn't expect.

Can you give a quick example, sure.

Find varlogdash name dot gz uses a show pattern dot gz to find filenames ending in GZ.

Simple okay, But.

Grep error zerosh nine plus farlow gap dot log uses a regular expression error zero zero nine plus to find lines inside the app dot log file that contain the word error followed by one or more digits.

Ah, Okay, one looks at the label, the other looks inside the box.

That's a great way to put it. Understanding that difference is vital for precise investigation.

Definitely. Okay. Let's shift gears into our first deep dive area defensive security operations with Bash. Using Bash as the investigator's toolkit, how do we usually frame defensive thinking?

Well, A really helpful framework is the five principles of cybersecurity Confidentiality, integrity, availability, non repudiation, and authentication, often called CIANA for short CIA. Briefly, confidentiality is about keeping secrets secret only authorized access. Integrity means making sure data hasn't been messed with it's trustworthy. Availability is ensuring systems and data are there when you need them right. Non Repudiation is about proof linking in action to a specific user

Okay, the core security goals.

Exactly, So the important question for us becomes, how does Bash, this command line tool actually help us maintain these principles, or maybe more importantly, how does it help us investigate when we suspect one of them has been violated?

That makes sense. It grounds what we're doing. So if we're thinking about actually doing defense or investigating an incident, say checking data integrity or figuring out the confidentiality impact of a breach, Bash becomes our hands on toolkit. Where do we start maybe data collection and analysis.

Absolutely, when something happens you need to gather evidence quickly and thoroughly. Bash gives you these direct tools. You've got simple things like cut to pull out specific columns of data file to quickly tell you what kind of file you're looking at, header tail to peak at the starter end of logs. The basics, the powerful, basic, And what's really neat is this isn't just a Linux Mac thing.

So you're not constantly switching mental gears between operating systems. What about grabbing log files, say for later analysis.

Super efficient. On Linux, you can package up all the logs in varlog into one compressed file, like sealing an evidence bag, with a command like tarh ccf O scs ez name logs, dot tr dot gz varlog easy.

Nice.

On Windows, you can script webtoodle to export all the different event logs. And here's a really powerful technique for remote systems, dotsh.

It cure shell.

Yeah, you don't even need to log into the remote machine. Sometimes you can run a command remotely like swash user at remote server command and get the output back on your local machine, or even run a local script on the remote machine like swash user at remote server, Bash, dash s dot mylocalscript, dot sh The script itself never has to be copied over there. It's efficient and sometimes stealthier.

Okay, that's very cool for quick data grabs. So once you have the data, maybe logs or files from a system, it can be a lot of data. How do you start searching through it effectively? With Bash?

Yeah, finding the needle in the haystack. Bash's fine command is your go to for searching based on filenames and other file attributes.

Like finding suspicious file.

Names exactly find dash name password. Could search the whole system for files with password in the name, use in name for case insensitive, or find hitting files which often start with a dot on Linux or Mac fine home name maagine. Remember that dot is a shell pattern matching file names starting with a dot.

Got it filenames? What about searching inside the files for keywords or indicators.

That's where GRIP comes in. Grap ir some directory suspicious pattern. The I makes it case insensitive, R makes it recursive through directories, and E specifies the pattern, which would typically be a regular expression here that you're looking for within the files.

Okay, find for names grap for content makes sense. What about checking if files have been tampered with that integrity piece?

Ah? Yes, Message digests or hashes tools like chess on some or md fivesome creator a unique digital fingerprint for a file. I could check some sort of but much more cryptographically strong. The key property is that changing even one single bit in the file will produce a completely different hash value.

Wow.

Okay, So if you calculate the hash of a critical system file and compare it to a known good value, you can tell instantly if it's been modified. It's a fundamental integrity check. You can script Bash to check hashes of many files very quickly.

Powerful stuff. Okay, moving on to data processing and analysis. You've collected logs, maybe found some interesting files. How does Bash help make sense of, say a massive web server log.

This is where combining tools with pipes really shines. Think about an Apache Access dot log, huge file, lots of lines. Right, you can use cut to extract just the IP address a the first field, then pipe that into sort, then pipe that into unique miss to count occurrences, and finally pipe that into sort. Dice on to see which ips made the most requests. Four simple commands chained together give you a top talkers list.

It's pretty neat turning raw logs into a summary exact.

Or you could use ak, which is brilliant for field based processing. Maybe you want to find which ips are getting lots of four O four not found errors, AC nine dollars easials four O four print one dollar. Access dot log could print the IP address field one from lines where the status code field nine is four oh four. Pipe that through your sertunic chain again.

Help spot reconnaissance scanning.

Maybe could be or maybe you want to see who's transferring the most data, use cut or ok to get the IP address and the number of bytes transferred. Then use another script maybe like the summer chistish example from the book, to total the bytes per IP. Sort that and a huge spike for one IP that might warrant investigation for data exultration.

Right, checking the confidentiality wasn't breached precisely, and you can even visualize this stuff simply in the terminal.

The book has examples like histogram dot ash that can take counts or totals and draw basic bar charts right there. Quick visual checks.

Very cool. Okay. One more defensive area real time log monitoring, watching things as they happen.

Yeah, super important for catching things early. The classic command here is tail dash F PATHTOLG file follow the file right. It just sits there and prints new lines as they get added to the end of the file. But the real power comes when you pipe that live stream.

Ah pipe tail dash f output.

Yes, pipe it into rep or egrep using the line buffered options, so it processes each line immediately, and you can filter that live stream for keywords or patterns so you can.

Watch for specific errors or maybe log in attempts exactly.

You could even build a simple lightweight intrusion detection system and IDs have a file say ioc dot txt with known bad patterns indicators of compromise like attempts to access sensitive files et cetera, paswd, or run commands pinch. Then you tail dash f your weblog and pipe it into egrep lineh buffer dash fioc dot txt. It will only show you the lines that match your bad patterns, alerting you in real time.

Wow. Okay, a homegrown IDs with just tail.

And rep pretty much, and you can do similar things on Windows. The book has a windtail dot sh script that uses web toodle in a loop to simulate tail dash f for Windows event logs.

Bringing that real time view to Windows logs too.

And you can take it further. There are scripts like webdash dot sh that use terminal control commands to create simple dashboards. They repeatedly run several commands, maybe monitoring different logs or system stats, and repaint the screen, giving you multiple live views in one terminal window.

Okay, so Bash is definitely a powerhouse for defense and investigation. Let's flip the coin now penetration testing with Bash. Thinking like an adversary. How does Bash fit into the attacker's toolkit? Is there a structure they follow?

Often yes, especially for more organized attackers. It's rarely just random hacking. A useful model to understand the phases is Mandiance attack life cycle. It lays out typical steps.

Okay, where are they?

There are about eight phases in that model. Reconnaissance first, then initial exploitation, establish foothold, escalate, privileges internal reconnaissance, move laterally inside the network, maintain presence, and and finally complete the mission whatever.

That might be. Recon exploit foothold, escalate, internal recon lateral movement, maintain complete. Got it?

Understanding that flow helps you see where tools including bashcripts might be used. It gives context to offensive actions. Bash makes an attacker very agile within this cycle.

That framework definitely helps visualize it. Given how quick and low profile Bash can be, where does it really shine in this attack cycle? Let's start at the beginning. Reconnaissance.

Reconnaissance is all about gathering intel in the target. Bash is great here. You can use kerl for example, to download web pages, maybe follow redirects to l save the output. Basically crawl website looking for information or vulnerabilities.

This is from the command line.

Yeah, and another classic technique is banner grabbing. Lots of network services like web servers, HGTP file servers, FTP mail servers SMTP. They announce themselves with a banner when you.

Connect, like a welcome message kind of.

And that banner often reveals the software name and version, maybe even the operating system gold dust for an attacker looking for known exploits.

And you can automate grabbing these banners with Bash absolutely.

But here's where Bash gets really sneaky and powerful, something that surprises people. You don't always need a dedicated tool like telnet or nmap to connect to a port and see that banner. No, Bash itself has this built in capability. Using a special filepath deftcfos nameport.

Wait, Bash can make TCP connections directly effectively.

Yes, it's a fetcher of the show. So an attacker on a system where maybe tools like telnet are removed or blocked, they can still perform network reconnaissance using just built in Bash commands. The book shows an SMTP connect dotsh script that uses exec three DVTCP one twenty five dollars to open a connection to an SMTP server on port twenty five and read its banner. No external tools needed.

WHOA Okay, that is sneaky, minimal.

Footprint exactly, pure command line resourcefulness.

Okay. So after recun the model had like establishing a foothold, getting persistence.

Right right Once you're in, you want a way to stay in or get back in easily. NC or netcat is often called the Swiss Army knife for networking. You can use it to create simple listeners, nclap port or make outbound connections.

For simple data transfer or shells.

Yes, and one very common technique for footholds is a reverse shell, especially using.

SSH versus SSH. How does that work?

Instead of the attacker connecting into the target, which might be blocked by a firewall, the compromised target machine initiates an outbound SSH connection to the attacker's machine using the natch R option SSR one two three four five dot local host part two to two attacker at attacker. This

Makes sense now. If attackers are using these tools, they probably don't want defenders easily figuring them out if they get caught. That brings us to script obfuscation.

Exactly, if your penetration testing script or your back door gets found, you don't want the blue team immediately understanding exactly how it works and what it did. Obfuscation makes reverse engineering harder.

How do you obfuscate a Bash script?

Several ways? Syntax obfuscation is the simplest. Just make the code hard to read. Put the whole script on one giant line, separated by semicolons. Use really meaningless variable and function names like afrioco.

Or funky one annoying to read. That's the point.

Then there's logic offuscation. This is where you add tons of useless code, pointless variables, functions calling other functions that do nothing important, complex loops that calculate something trivial. Makes a simple script look incredibly.

Complicated, like hiding a needle in a bigger messier astac.

Pretty much, but the most effective method is usually encryption. Okay, The basic idea is you have your real script plaintext. You encrypt it using a key producing ciphertext. You can use standard tools like ohensolars two thousand, CBC sll inrelscript dot sa outencrypted dot dot dot a password. Then you create a small rapper script. This wrapper contains the encrypted

Soli executes from memory much harder to recover the original script, much harder.

Bash, which can even be used to demonstrate simple xor stream ciphers like the stream cipher dot sh example, using the random variable and a seed for educational purposes, showing the principles involved fascinating.

Okay, one more offensive technique fuzzing. What is that exactly?

Fuzzing is basically throwing junk at a program to see if it breaks. It's an automated way to find vulnerabilities, particularly thing like buffer overflows.

Buffer overflows where the program tries to stuff too much data into a small.

Space exactly classic C programming vulnerability With functions like strikeat they copy data from one place to another, but don't always check if the destination has enough room. If you send way too much data, it spills over overwriting adjacent memory, potentially crashing the program, or worse, allowing an attacker to inject malicious code. So a fuzzer, often just a simple script, systematically sends slightly different, often invalid or overly long inputs

Automated vulnerability discovery yep.

Bash is great for scripting that kind of repetitive testing.

So we've seen Bash used for defense and offense. How do these two sides connect?

Well? If we connect, this all back to the bigger picture. Understanding these attack methods is directly useful for defense. Knowing your enemy precisely. If you know how an attacker might use DEVTCP for banner grabbing or set up a reverse SSH tunnel, you know what kind of network traffic or process behavior to look for on your systems, you can figure firewalls better, maybe monitor for suspicious outbound connections. Knowing how a Bash backdoor works helps you spot those weird

So what does this all really mean for you? The listener trying to learn this stuff? This deep dive? I think really Hammers home that Bash isn't just some utility for moving files around, not at all. It's this incredibly powerful, versatile language right at the heart of cybersecurity. Doesn't matter if you're Red Team or Blue Team. It's a foundational skill that just amplifies everything else.

You do, which raises the important question, how can you actually practice these skills? Make them real?

Good question? Reading is one thing doing as another exactly, And.

The book actually has some really good practical workshop props to get you hands on. They're great starting points.

Oh yeah, like what well?

For example, you could try modifying one of the data collection scripts like get local dot shsh to automatically upload its findings to a secure server using CPP automate your evidence collection.

Okay, practical.

Or take the hash search dot s script, the one that finds files by their hash. Modify it so it stops searching as soon as it finds the first match. Make it more efficient, or maybe simplify the output paths it displays, tidying it up. Or for Windows, enhance the windlogs dot sh sh script to show a progress bar while it's working using tiput make it more user friendly.

Nice little touches.

On the offensive side. You could expand the fuzzer dot sh syncrypt to fuzz more than one command line argument at a time, make it a bit more thorough, or modify the banner grabber dot sh script instead of just one target, make it read a whole list of IPS from a file and output the results neatly into an htmel table for reporting. That sounds useful, and definitely try encrypting a simple script yourself using open sale or even the xor method and then write the rapper script to

Get your hands dirty with encryption exactly.

This kind of exercises really bridge that gap from just reading about it to actually doing it.

Absolutely so, mastering the command line using Bash like this. It's not about throwing away your fancy graphical security tools, noah, not at all. It's about augmenting them, adding this fundamental layer of control and insight that maybe you didn't realize you had access to.

Well said, I mean, the command line is your direct pipe to the OS. Right. All that power refined over decades in a world where we're increasingly using these slightly opaque GUIs understanding and being able to wield this direct power.

That's a great question to chew on something powerful hidden in plain sight. Well that's all the time we have for this deep dialk into cybersecurity ops with Bash. We hope you found it useful.

Yeah, hope it sparks some ideas.

Thanks for joining us, and we'll catch you on the next deep dive.