Speaker 1: Welcome back everyone for another deep dive. This time we're
Speaker 1: putting on our digital detective hats and uh yeah, we're
Speaker 1: diving headfirst into the world of Linux forensics.
Speaker 2: Oh, Linux forensics, that's my jam.
Speaker 1: And to guide us on this thrilling adventure, we have
Speaker 1: doctor Philip Polster's book. Now, this isn't your typical dry
Speaker 1: technical manual.
Speaker 2: No, no, not at all.
Speaker 1: It's more like a gripping detective story. You know, even
Speaker 1: if you've never ever touched a command line, you'll feel
Speaker 1: like you're cracking a real life cybercrime case.
Speaker 2: He's got this way of making the technical stuff feel
Speaker 2: almost like cinematic.
Speaker 1: Oh. Absolutely.
Speaker 2: He walks you through this case right where a company
Speaker 2: they're called Phil's Awesome Stuff, they get slammed with a
Speaker 2: cyber attack. Their web server has been compromised, data's potentially stolen,
Speaker 2: the whole shebang.
Speaker 1: Oh man.
Speaker 2: He uses this story right to teach you the ropes
Speaker 2: of Linux forensics.
Speaker 1: I love that approach, learning through a story. So we're
Speaker 1: going to use this Phills Awesome stuffcase as our guide,
Speaker 1: and our mission, should we choose to accept it, is
Speaker 1: to equip you, dear listeners, with the knowledge tackle a
Speaker 1: digital investigation head on.
Speaker 2: That's right. And one of the first things you realize
Speaker 2: in these situations is that your gut instinct, well it
Speaker 2: might lead you astray. Oh really yeah, Like you see
Speaker 2: a compromise system, you want to shut it down immediately, right.
Speaker 1: Contain the damage seems logical.
Speaker 2: Yeah, yeah, exactly, contained the damage. But as Polster points out,
Speaker 2: that could actually be the worst move.
Speaker 1: No, I'm really intrigued. Why would leaving a compromise system
Speaker 1: running be like the right call?
Speaker 2: Well, think about it this way. If you had like
Speaker 2: a burglar in your house and they knew you were
Speaker 2: onto them, what would they do.
Speaker 1: They'd try to cover their tracks, get rid of any evidence.
Speaker 2: Exactly, same thing with malware. If it senses the system
Speaker 2: shutting down, it's like hitting the panic button. It might
Speaker 2: wipe its activity logs, delete those stolen files.
Speaker 1: So it basically disappears in the thin air poof gone wow.
Speaker 1: So it's this like aast time. But sometimes hitting the
Speaker 1: pause button actually helps the criminal, not.
Speaker 2: Us exactly, And this is just one example of how
Speaker 2: counterintuitive digital forensics can be. Polster also talks about this
Speaker 2: thing called confirmation bias.
Speaker 1: Confirmation bias, Yeah, it.
Speaker 2: Could trip up even the most seasoned investigators.
Speaker 1: Now, isn't confirmation bias, like when you're so convinced you're
Speaker 1: right that you just ignore any evidence that says otherwise.
Speaker 2: You got it? Polster uses this analogy. It's like a
Speaker 2: magician asks a child to guess which hand has the coin.
Speaker 1: Right, Okay, I'm following, and.
Speaker 2: The child keeps getting right, and the parents they're convinced, Oh,
Speaker 2: my kid's a mind reader. But the magician, sneaky magician,
Speaker 2: had coins in both hands all along.
Speaker 1: Oh wow, So the parents were so focused on proving
Speaker 1: their kid a special that they totally missed the obvious.
Speaker 2: Exactly, And investigators can fall into that same trap. They
Speaker 2: get fixated on one theory and then they only see
Speaker 2: the evidence that supports it. Yeah, we've got to turn
Speaker 2: a blind eye to other possibilities.
Speaker 1: Right, It's like having tunnel vision. So that's a good
Speaker 1: reminder for all of us, right to stay open minded,
Speaker 1: consider all the angles. Absolutely, But before we get ahead
Speaker 1: of ourselves, let's take a step back for those who
Speaker 1: are just starting out, Like, how would you define forensics,
Speaker 1: especially in this digital world?
Speaker 2: Okay, so forensic science at its core, it's about gathering
Speaker 2: evidence that could hold up in court, even if you
Speaker 2: never actually plan on going to court. Got it so
Speaker 2: about being meticulous, documenting everything, following procedures.
Speaker 1: Right, dotting your eyes, crossing your t's.
Speaker 2: Yeah, and ensuring that all your findings, everything you discover
Speaker 2: is credible and hasn't been tampered with.
Speaker 1: So it's not just about finding those clues, it's about
Speaker 1: doing it in a way that's like legit that can
Speaker 1: stand up to scrutiny.
Speaker 2: Exactly. In digital forensics, it's particularly tricky because digital evidence
Speaker 2: is so easy to change, delete, even fabricate.
Speaker 1: Oh that's right.
Speaker 2: It's like imagine trying to solve a crime scene, but
Speaker 2: the evidence can just vanish or morph into something else
Speaker 2: at any given moment.
Speaker 1: Oh wow, that's a great way to put it. So
Speaker 1: we're dealing with much more fragile evidence than say, fingerprints
Speaker 1: or I don't know, DNA.
Speaker 2: Right. But here's the interesting part digital evidence. It also
Speaker 2: leaves behind a ton of information that you know, traditional
Speaker 2: forensics can only dream of.
Speaker 1: Oh that's true.
Speaker 2: We're talking time stamps, file access logs, internet history. I mean,
Speaker 2: the list goes on and on.
Speaker 1: So it's a double edged sword, right, It is more fragile,
Speaker 1: but also potentially way more revealing exactly.
Speaker 2: And this brings us back to low cards exchange principle,
Speaker 2: which is like the couinderstone of forensic science.
Speaker 1: Okay, remind me what's low cards exchange principle again.
Speaker 2: It basically states that whenever two objects interact, they leave
Speaker 2: traces on each other, right, right, So like paint transfer
Speaker 2: in a car accident, fingerprints at a crime scene. Well,
Speaker 2: in the digital world, those traces, those digital footprints, they're
Speaker 2: often even more numerous and detailed.
Speaker 1: Oh that's interesting. So every click, every download, every email,
Speaker 1: every like everything is leaving a mark somewhere.
Speaker 2: You got it. And that's why in this Fills Awesome
Speaker 2: Stuff case, Polstra really emphasizes preserving that digital crime scene
Speaker 2: as meticulously as possible.
Speaker 1: Okay, it makes sense. So let's say we're called in
Speaker 1: to investigate this compromise web server at Phill's Awesome Stuff.
Speaker 1: What are like the first things we need to keep
Speaker 1: in mind? What are the guiding principles as we start
Speaker 1: our investigation.
Speaker 2: Okay, the absolute top priority, the golden rule, is maintaining
Speaker 2: the integrity of the evidence. Think of it like this,
Speaker 2: any action you take on a compromised system. Even something small,
Speaker 2: it has the potential to change the original state. So
Speaker 2: before you even touch the system, you got to make
Speaker 2: a forensic copy of the hard drive.
Speaker 1: No, it's not just like copying and pasting files, right,
Speaker 1: we're talking about a bit for bit replica, a clone
Speaker 1: of the entire drive. Why is that so crucial.
Speaker 2: Because even something that seems harmless, like just opening a file,
Speaker 2: it can change the file's metadata at a day.
Speaker 1: That's the time stamps, that access records, all that behind
Speaker 1: the scenes stuff, you.
Speaker 2: Got it, all that juicy stuff that helps us reconstruct
Speaker 2: the what happened the timeline.
Speaker 1: So we're working on a copy to avoid messing up
Speaker 1: the original evidence exactly.
Speaker 2: And while we're preserving that evidence, we got to document
Speaker 2: every single step we take during the investigation. Makes us
Speaker 2: who accessed what, when and for what reason.
Speaker 1: Oh so that creates a chain of custody, that's.
Speaker 2: Right, the chain of custody proving that the evidence is
Speaker 2: authentic and hasn't been tampered with.
Speaker 1: So it's not just about catching the bad guy, it's
Speaker 1: about doing it in a way that's airtight, you know,
Speaker 1: like building a legal case alongside the technical investigation.
Speaker 2: Percisely.
Speaker 1: Okay, So documentation super important. Are there any other standard
Speaker 1: practices or guidelines that are like super crucial in Linux forensics.
Speaker 2: Yeah, sticking to established procedures, that's super important. It's like
Speaker 2: having a recipe, you know, for your investigator.
Speaker 1: A recipe, okay, Yeah.
Speaker 2: It ensures consistency, helps you avoid makeing those silly mistakes,
Speaker 2: and makes your findings more credible in the end.
Speaker 1: So it's not just about doing things right, it's about
Speaker 1: doing them in a like a standardized, replicable way, like
Speaker 1: a scientific method, but for digital detective work exactly.
Speaker 2: And Polstra in his book he outlines these procedures. He
Speaker 2: walks you through the three main phases of a digital
Speaker 2: investigation out.
Speaker 1: There are phases.
Speaker 2: There are you got evidence preservation, which we just talked about.
Speaker 2: Then there's the searching phase where you're digging through the
Speaker 2: data for those clues. And finally event reconstruction.
Speaker 1: Event reconstruction, so you secure the scene, then you hunt
Speaker 1: for clues, and then finally you try to piece together
Speaker 1: like the narrative, what actually happened.
Speaker 2: You got it. But in practice, those phases they often overlap,
Speaker 2: you know, they kind of blur together.
Speaker 1: Yeah, and see that.
Speaker 2: Like, for example, that dilemma of pulling the plug, you know,
Speaker 2: shutting down the system, right, right, that decision you often
Speaker 2: have to make that during the evidence preservation phase.
Speaker 1: Oh, that's right, because the longer the system is running,
Speaker 1: the more time the malware has to cover its tracks.
Speaker 1: But shutting it down could mean losing vital data. It's
Speaker 1: like a catch twenty two exactly.
Speaker 2: It's a tough call and there's no one size fits
Speaker 2: all answer, you know. It depends on the situation, the
Speaker 2: type of malware we're dealing with, what we're hoping to achieve.
Speaker 1: So sometimes it's a judgment call, right, weighing those risks
Speaker 1: and benefits of each action precisely.
Speaker 2: And this leads us to kind of the idea of
Speaker 2: dead versus live.
Speaker 1: Analysis, Dead versus live what's that?
Speaker 2: So? Dead analysis that's when we're examining a system that's offline.
Speaker 1: Offline, Yeah, like.
Speaker 2: Analyzing that disk imagery talked about. Live analysis, Well, that's
Speaker 2: when we're interacting with a system that's still running.
Speaker 1: Okay, So dead analysis is like studying a frozen snapshot.
Speaker 2: Yeah.
Speaker 1: Well, live analysis is more like observing the system in
Speaker 1: action as it's happening.
Speaker 2: That's a great way to put it. Both approaches have
Speaker 2: their you know, pluses and minuses, advantages and disadvantages. Yeah,
Speaker 2: and the choice it really depends on the goals of
Speaker 2: the investigation.
Speaker 1: Makes sense. Okay, So let's say we've decided to do
Speaker 1: some analysis. What kind of tools would we need in
Speaker 1: our digital detective kit? Ah, the tools I'm picturing like
Speaker 1: something straight out of a spy movie.
Speaker 2: Well, on the hardware side, you'll need external hard drives,
Speaker 2: you know, to store those forensic copies.
Speaker 1: Right.
Speaker 2: USB three point zero is usually the best. It's fast, okay,
Speaker 2: but sometimes those older USB two point zero drives. They're
Speaker 2: better for compatibility with virtual machines, oh okay. And absolutely
Speaker 2: essential are right blockers.
Speaker 1: Right blockers.
Speaker 2: Yeah, they prevent you from accidentally modifying the evidence.
Speaker 1: So it's like a safety guard for our digital evidence exactly.
Speaker 2: Think of them as like gloves for a surgeon. You know,
Speaker 2: you wouldn't operate without gloves, and you shouldn't image a
Speaker 2: drive without a right blocker.
Speaker 1: Good analogy. And you want to dedicate a forensics workstation
Speaker 1: right absolutely completely separate from the compromise system.
Speaker 2: Yeah, you don't want to be installing anything on the
Speaker 2: suspect machine. You got to work on a copy on
Speaker 2: a separate system to avoid any contamination.
Speaker 1: Right, makes sense, But what about software? Do we need
Speaker 1: expensive specialized tools for this?
Speaker 2: Here's the beauty of Linux forensics. There are tons of
Speaker 2: free and open source tools out there that are incredibly powerful.
Speaker 1: Oh that's awesome.
Speaker 2: And Polstra he actually includes a script in his book
Speaker 2: that installs a whole bunch of these tools automatically.
Speaker 1: Oh wow, So it's like setting up your digital forensics
Speaker 1: lab with a single command.
Speaker 2: That's the idea.
Speaker 1: That's amazing. It sounds like Linux is a great platform
Speaker 1: for this kind of work.
Speaker 2: It really is. But remember, no matter how powerful your
Speaker 2: tools are, the key is to use them responsibly ethically.
Speaker 1: Right, of course, our.
Speaker 2: Goal is to minimize disturbance to the subject system. Think
Speaker 2: of it like walking through a like a delicate crime scene.
Speaker 2: You want to leave the smallest footprint.
Speaker 1: Possible, right, So avoid installing anything on the suspect system,
Speaker 1: create that copy first, and use those tools responsibly.
Speaker 2: Got it exactly. And when it comes to discreetly gathering data,
Speaker 2: tools like net cat can be incredibly handy.
Speaker 1: Netcat that sounds like something a hacker would use.
Speaker 2: It can be used for both good and bad. But
Speaker 2: in our context, it's a way to create a secure
Speaker 2: channel between the suspect system and our workstation. We can
Speaker 2: send commands, get data back, all without leaving a trace
Speaker 2: on the compromise machine.
Speaker 1: Okay, so netcat is like our secret back door for
Speaker 1: collecting evidence. I'm starting to feel like a real digital
Speaker 1: detective here.
Speaker 2: That's the spirit.
Speaker 1: This is exciting.
Speaker 2: It's a combination of technical skills and that old fashioned
Speaker 2: detective intuition.
Speaker 1: Well said, So we've gathered our initial data, we've got
Speaker 1: our tools ready to go, and now we're about to
Speaker 1: enter the live analysis phase. Live analysis here we go,
Speaker 1: assuming of course, that we've determined there's actually an incident
Speaker 1: to investigate. Where do we even begin.
Speaker 2: One of the first things to zero in on is
Speaker 2: file metadata.
Speaker 1: File metadata, Yeah.
Speaker 2: Timestamps, permissions, ownership, all those little details can be incredibly revealing.
Speaker 1: So it's like reconstructing the story of what happened, and
Speaker 1: based on when and how files were created, modified, or accessed.
Speaker 2: You got it, and don't forget about user command history.
Speaker 2: It can give us a glimpse into what actions both
Speaker 2: legitimate users and potential attackers took on the system.
Speaker 1: Oh, right, like a trail of digital breadcrumbs exactly.
Speaker 2: And log files they are another gold mine of information
Speaker 2: system events, log in attempts, air messages, it's all there,
Speaker 2: just waiting to be analyzed.
Speaker 1: Wow. So it's like having a detailed chronicle of the
Speaker 1: system's activity.
Speaker 2: Precisely, and sometimes we need to go even deeper and
Speaker 2: capture the entire system state. That's where ram dumps come.
Speaker 1: In a ramdomp, what's that all about.
Speaker 2: It's basically creating a snapshot of everything that's in the
Speaker 2: computer's memory at a specific moment in time. It's like
Speaker 2: freezing the brain of the computer, seeing what it was
Speaker 2: thinking at that exact moment.
Speaker 1: That's impressive, but I imagine it's pretty challenging to do.
Speaker 2: It can be tricky, but there are tools designed specifically
Speaker 2: for this purpose. One of them is called line BLI me. Yeah,
Speaker 2: capturing a complete an accurate RAM dump is a delicate process,
Speaker 2: but the insights you can glean from it, they're often invaluable.
Speaker 1: Okay, so we've collected that volatile data from the running system,
Speaker 1: but what about the data stored on the hard drive itself.
Speaker 2: That's where disk images come into play.
Speaker 1: Disk images creating a.
Speaker 2: Forensic image of the hard drive is crucial for preserving
Speaker 2: the evidence and ensuring we have a complete copy to
Speaker 2: work with.
Speaker 1: Right, So it's not just copying files, but creating a
Speaker 1: bit for bit replica of the entire drive.
Speaker 2: You, got it. And there are different formats for these images,
Speaker 2: like raw images. Those are exact copies, and then there
Speaker 2: are proprietary formats that offer compression or some extra features.
Speaker 1: Okay, And which tools are commonly used to create these images.
Speaker 2: DD is a classic a command line tool, but for forensics
Speaker 2: we often use DCFLTD DCLLTD. Yeah, it's basically like DD
Speaker 2: on steroids.
Speaker 1: DC LTD on steroids. That sounds intense.
Speaker 2: It's more robust, more reliable. It has features like verifying
Speaker 2: the integrity the image as it's been created and splitting
Speaker 2: it into multiple files if you need to.
Speaker 1: Oh, that's handy.
Speaker 2: And of course we always use it in conjunction with
Speaker 2: a right blocker, just to be extra careful.
Speaker 1: Right, safety first, So it's.
Speaker 2: Like having a safety net, a quality control check all
Speaker 2: rolled into one.
Speaker 1: Got it. And if possible, it's always best to image
Speaker 1: the entire drive, right, right, not just specific partitions.
Speaker 2: Yeah, you never know where those valuable clues might be hiding.
Speaker 1: Makes sense. It's like searching every nook and cranny of
Speaker 1: the digital crime scene. So we've created our image, what's next.
Speaker 2: The next step is to mount the image. Mount it, yeah,
Speaker 2: which basically means making it accessible to our forensic tools
Speaker 2: as if it were a physical drive plugged into our workstation.
Speaker 1: Oh okay, so it's like virtually plugging in the hard
Speaker 1: drive and exploring its content exactly.
Speaker 2: But before we mount the image, we need to figure
Speaker 2: out its partitioning scheme.
Speaker 1: Partitioning scheme, yeah, it's.
Speaker 2: Basically how the drive is divided up into these logical sections.
Speaker 1: Oh right, right, like those C and D drives and
Speaker 1: Windows exactly.
Speaker 2: Yeah. But Linux it uses different partitioning schemes.
Speaker 1: Oh okay.
Speaker 2: The most common ones are MBR, which is the older scheme,
Speaker 2: and then there's GP, which is newer and can handle
Speaker 2: much larger drives.
Speaker 1: Okay, so GPT is the way to go, right if
Speaker 1: we're dealing with a modern system.
Speaker 2: Ideally, yes, but for compatibility reasons, you really need to
Speaker 2: know both. Think of it, like knowing both metric and
Speaker 2: imperial measurements. Sometimes you encounter those older systems that still cling.
Speaker 1: To the old ways, right, right, So how do we
Speaker 1: figure out the partitioning scheme of our disk image?
Speaker 2: We use a tool called f disc. It's a command
Speaker 2: line utility that can analyze the drive without making any changes. Okay,
Speaker 2: kind of like a harmless X ray.
Speaker 1: So it's like reading the blueprint of the drive, seeing
Speaker 1: how it's structured and where each partition is located exactly.
Speaker 2: And once we have that information, we can use the
Speaker 2: mount command to make those specific partitions accessible for analysis.
Speaker 1: Sound straightforward enough, but I imagine it can get pretty
Speaker 1: tedious if you're dealing with a lot of partitions.
Speaker 2: You're right. That's where scripting can be a lifesaver. Polster's
Speaker 2: book shows you how to automate this whole process using Python.
Speaker 1: Oh.
Speaker 2: Python, Yeah, it's like having a robot assistant handling all
Speaker 2: those repetitive tasks.
Speaker 1: So we can write these Python scripts to identify the
Speaker 1: partitioning scheme, locate the partitions, and mount them all automatically exactly.
Speaker 2: It makes the whole process much more efficient and less
Speaker 2: prone to those pesky human errors. And speaking of efficiency,
Speaker 2: importing filesystem data into a database, now that can be
Speaker 2: a real game changer for analysis databases.
Speaker 1: Yeah, now I thought those were for like storing structured
Speaker 1: data like customer information or financial transactions.
Speaker 2: They are, but they can also be incredibly powerful tools
Speaker 2: for forensic analysis. Okay, imagine having this supercharged search engine
Speaker 2: for all your evidence. Instead of manually digging through those files,
Speaker 2: you can use SQL queries to pinpoint very specific information,
Speaker 2: identify patterns, generate timelines, and all much much faster.
Speaker 1: Oh wow, Okay, that's starting to sound really useful. Can
Speaker 1: you give me like a concrete example of how this
Speaker 1: might work.
Speaker 2: Sure, Let's say you suspect that someone was stealing sensitive
Speaker 2: data from Phil's awesome stuff. With a database, you could import,
Speaker 2: like the file axislogs user login records and then write
Speaker 2: a query that says, show me all the files accessed
Speaker 2: by this specific user during these specific hours, and tell
Speaker 2: me whether those files were sent over the network.
Speaker 1: Wow, that's incredibly specific. It's like having laser focus on
Speaker 1: the exact data we need exactly.
Speaker 2: And databases they allow for much more complex queries than
Speaker 2: your typical forensic tools.
Speaker 1: So it's not just about finding a needle in a haystack,
Speaker 1: it's about analyzing the whole haystack in seconds.
Speaker 2: You got it, impolster. He actually shares a real world
Speaker 2: case where those prepackaged forensic tools that were just hitting
Speaker 2: their limits and importing the data into a database, Well
Speaker 2: that's what allowed him to crack the case wide open.
Speaker 1: Wow, I'm starting to see why databases are becoming so
Speaker 1: essential in digital forensics. But let's step back for a
Speaker 1: moment and talk about timeline analysis. Timeline analysis, you've mentioned
Speaker 1: it a few times already. Yeah, how do we even
Speaker 1: go about creating a timeline of events on a compromise system?
Speaker 1: And like, how reliable is that timeline? Can we trust it?
Speaker 2: Creating a timeline it's often the key to figuring out
Speaker 2: what happened. And when we use time stamps from files,
Speaker 2: from log in records, system logs, any source we can
Speaker 2: get our hands on.
Speaker 1: Oh okay, pulling it all together.
Speaker 2: But here's the catch time stamps.
Speaker 1: They can be manipulated, so we can't just take them
Speaker 1: at face value. We need to be like skeptical exactly.
Speaker 2: Think of time stamps as clues, not absolute truths. You
Speaker 2: got to look for inconsistencies, suspicious patterns, time stamps that
Speaker 2: just don't make sense in the context of other evidence.
Speaker 1: Okay, So, like if we see a file modified before
Speaker 1: it was supposedly created, that's a red flag.
Speaker 2: Big red flag. Or if all the time stamps are
Speaker 2: like suspiciously rounded to the nearest hour, that could mean
Speaker 2: someone was trying to cover their tracks.
Speaker 1: It's like noticing that all the clocks in a suspect's
Speaker 1: house are set to the same time, even though they
Speaker 1: were supposedly set independently.
Speaker 2: That's a great analogy. And besides timestamps, another useful tool
Speaker 2: for timeline analysis is the last command. It shows a
Speaker 2: history of user logins on the system.
Speaker 1: Oh okay, so we can see who logged in, when
Speaker 1: they logged in, and even where they logged in from.
Speaker 2: You got it? And this information, combined with other log files,
Speaker 2: it can help us spot unusual log in patterns, track
Speaker 2: user activity, and potentially pinpoint the exact time frame of
Speaker 2: the security incident.
Speaker 1: Okay, so we've got time stamps, timelines, and user log
Speaker 1: in records. But now I'm curious about the filesystems themselves.
Speaker 1: What makes Linux file systems unique? What are the quirks
Speaker 1: we need to be aware of from a forensic perspective.
Speaker 2: Well, the X file system it's commonly used in Linux.
Speaker 2: It has its own quirks and intricacies.
Speaker 1: Okay.
Speaker 2: Understanding concepts like inodes, data blocks, indirect blocks, all that stuff.
Speaker 2: It's crucial for effective forensic analysis.
Speaker 1: Inodes, data blocks. It sounds like we're entering a within
Speaker 1: the hard drive.
Speaker 2: Think of it this way. The inode, that's like a
Speaker 2: file's identity card. Okay, it contains all that metadata, the timestamps,
Speaker 2: ownership permissions.
Speaker 1: So the inode tells us who the file belongs to,
Speaker 1: when it was created or modified, and what kind of
Speaker 1: access permissions it has.
Speaker 2: You've got. And the data blocks, well, that's where the
Speaker 2: actual content of the file is stored.
Speaker 1: So if we're trying to recover a deleted file, we
Speaker 1: need to find both the inode and the data blocks.
Speaker 2: You got it. And within the X filesystem there are
Speaker 2: also these things called extended attributes and access control lists.
Speaker 2: They can be used to store additional information about files.
Speaker 1: Additional information like what kind of information it could be,
Speaker 1: anything really, from security settings to user defined data.
Speaker 2: And attackers they're clever. Sometimes they exploit these features to
Speaker 2: hide data or malicious code.
Speaker 1: Oh sneaky. So it's like they're playing a digital game
Speaker 1: of hide and seek with us.
Speaker 2: Exactly, And As filesystems evolve, they introduce new features, okay,
Speaker 2: like extents, which are a more efficient way to manage
Speaker 2: large files, but they can also be more complex to
Speaker 2: analyze from a forensic standpoint.
Speaker 1: So the landscape's always changing, always presenting new challenges for
Speaker 1: both the attackers and the investigators.
Speaker 2: It is. It's a constant cat and mouse game.
Speaker 1: That's what makes this feel so exciting, right exactly.
Speaker 2: It's a constant learning process. There's always something new to discover.
Speaker 1: Okay, so we've got a grasp of the basics of
Speaker 1: the X file system, but let's bring it back to
Speaker 1: your case fills awesome stuff. How did Polstra use this knowledge,
Speaker 1: this file system knowledge, to unravel the mystery of that
Speaker 1: compromised web server.
Speaker 2: Well, he used a few techniques, one of them being
Speaker 2: analyzing a RAM dump with a tool called volatility.
Speaker 1: Volatility that sounds familiar.
Speaker 2: We talked about it earlier, remember when we were discussing
Speaker 2: live analysis.
Speaker 1: Oh right.
Speaker 2: Volatility is a powerful tool. It lets us analyze the
Speaker 2: contents of RAM even after the system has been shut down.
Speaker 2: In this case, Polstry used it to uncover hidden processes
Speaker 2: and files that wouldn't have been visible through normal file
Speaker 2: system analysis.
Speaker 1: Oh wow, so it's like using x ray vision right
Speaker 1: exactly to see beneath the surface of the operating system.
Speaker 2: You got it.
Speaker 1: And he also used network traffic analysis, right, he did
Speaker 1: to kind of trace the attacker's activity, reveal those suspicious connections,
Speaker 1: maybe even backdoors.
Speaker 2: Precisely so volatility it helped him understand what was happening
Speaker 2: on the system itself, and then the network traffic analysis
Speaker 2: showed him how the attacker was interacting with the outside world.
Speaker 1: Okay, so he's putting together the pieces both internally and
Speaker 1: external exactly.
Speaker 2: And by combining those techniques, Polster was able to build
Speaker 2: a really compelling narrative of the attack, ultimately leading to
Speaker 2: the identification and apprehension of the culprit.
Speaker 1: That's amazing. This fills awesome stuff case. It's a great
Speaker 1: example of how powerful Linux forensics can be. But I
Speaker 1: feel like we've only scratched the surface here.
Speaker 2: Oh, we've just begun. There's a whole world of advanced
Speaker 2: techniques and specialized tools out there.
Speaker 1: Well, I guess that means we need to dive even deeper.
Speaker 2: Right, let's do it.
Speaker 1: But before we do, left, take a moment to recap
Speaker 1: some of the key takeaways from this first part of
Speaker 1: our investigation sounds good. What stood out to you as
Speaker 1: particularly interesting or maybe unexpected? So far?
Speaker 2: Oh, there's so much Where do we even begin.
Speaker 1: Honestly, that whole idea of shutting down a compromise system
Speaker 1: could actually be the wrong move. That was the real
Speaker 1: eye opener for me. It's counterintuitive. You think you're containing
Speaker 1: the damage, but you might actually be helping the attacker
Speaker 1: cover their tracks.
Speaker 2: It is, isn't. It's one of those things you only
Speaker 2: learned through experience or by reading Polster's book, I guess
Speaker 2: And in that Fills Awesome stuff case, he actually he
Speaker 2: emphasizes talking to the users as like one of the
Speaker 2: first steps.
Speaker 1: Oh interesting. So good old fashioned human intelligence still crucial
Speaker 1: even in a high tech cybercrime investigation.
Speaker 2: Absolutely. Users can often provide insights that no amount of
Speaker 2: technical analysis can you uncover. They might have noticed something strange,
Speaker 2: like odd behavior on their computer, or recent software in
Speaker 2: stations that shouldn't be there, or even you know, potential
Speaker 2: security lapses. Things they could point us in the right direction.
Speaker 1: Right, So it's like interviewing witnesses at a crime scene. Right,
Speaker 1: they might have seen or heard something crucial that helps
Speaker 1: you piece together the puzzle precisely.
Speaker 2: And sometimes just talking to the users can quickly debunk
Speaker 2: a suspected incident. Maybe a system administrator was performing like
Speaker 2: routine maintenance and that triggered some unusual activity that was
Speaker 2: mistaken for a security breach.
Speaker 1: Oh okay, So it's always good to get the full story,
Speaker 1: all perspectives before jumping to conclusions. But what are some
Speaker 1: of the key questions we should be asking these users?
Speaker 1: Like what kind of information are we really looking for?
Speaker 2: You want to start with open ended questions? Well, if
Speaker 2: it ended, yeah, things like what makes you think there's
Speaker 2: a problem, or can you describe what you've observed? You know,
Speaker 2: encourage them to share their perspective, and that can often
Speaker 2: lead to unexpected insights.
Speaker 1: So it's about understanding their concerns and getting them to
Speaker 1: like really elaborate on what they've seen or experienced exactly.
Speaker 2: And don't underestimate the power of of you know, active listening.
Speaker 2: Pay attention to their tone of voice, body language, What
Speaker 2: details do they emphasize, what do they kind of downplay?
Speaker 2: You know, sometimes what's not said can be just as
Speaker 2: revealing as what I have said, Right.
Speaker 1: It's like reading between the lines, picking up on those
Speaker 1: subtle cues that might point you in the right direction.
Speaker 2: Right, And while you're gathering all this information, don't forget
Speaker 2: to document everything. Use a notebook, voice recorder, whatever works
Speaker 2: best for you, but make sure you have a clear
Speaker 2: and accurate record of the conversation.
Speaker 1: Right back to that crucial documentation step. But you know,
Speaker 1: taking notes on a laptop during an interview, I feel
Speaker 1: like it can be a bit distracting, both for you
Speaker 1: and the person you're talking to. It creates this barrier between.
Speaker 2: Oh, absolutely, a good old fashioned notebook, you know, pen
Speaker 2: and paper. It's often the best tool for taking notes
Speaker 2: during those interviews. It's less intrusive, you can jot down
Speaker 2: key points quickly, and it doesn't create that psychological distance
Speaker 2: that you know a laptop screen sometimes.
Speaker 1: Can, right about fostering a more natural conversation exactly.
Speaker 2: And besides all the information you gather from the users,
Speaker 2: you want to document everything you know about the subject
Speaker 2: system itself. Okay, what operating system are they running, what
Speaker 2: software is installed? Are there any known vulnerabilities?
Speaker 1: Right, So it's like building a profile, almost understanding its
Speaker 1: strengths and weaknesses before you even start digging into the.
Speaker 2: Evidence precisely, and you know, if it seems appropriate, you
Speaker 2: might even want to snap a picture of the computer
Speaker 2: and its surroundings.
Speaker 1: Oh, like a crime scene photo. But why is that
Speaker 1: necessary in a digital investigation, Well, it can provide context.
Speaker 2: Maybe there's a sticky note on the monitor with a
Speaker 2: password written on it. Oh, or the computers located in
Speaker 2: an area with like really lacks physical security. Those seemingly
Speaker 2: insignificant details, they can sometimes be incredibly revealing.
Speaker 1: It's a good reminder that physical and digital security are
Speaker 1: often like intertwined. They go hand in hand exactly.
Speaker 2: And once you've gathered all this eliminary information, you know,
Speaker 2: talk to the users documented the system. You're finally ready
Speaker 2: to start interacting with the subject system itself. But before
Speaker 2: you do, remember that golden rule of digital forensics.
Speaker 1: Minimize disturbance, right, we talked about that earlier. It's like
Speaker 1: avoiding contamination at a crime scene. Don't touch anything you don't.
Speaker 2: Have to precisely, And one way to minimize disturbance is
Speaker 2: to use what we call known good binaries.
Speaker 1: Known good binaries and what are those?
Speaker 2: They're basically trusted, verified copies of the tools we need
Speaker 2: to use during our investigation. Think of them like sterile
Speaker 2: instruments for a digital surgery.
Speaker 1: Okay, so we're not installing any potentially compromised software on
Speaker 1: the suspect machine. We're bringing our own clean.
Speaker 2: Tools exactly, these known good binaries. They're usually stored on
Speaker 2: a separate secure device, like a USB drive, and we
Speaker 2: boot the subject system from that device to perform our analysis.
Speaker 1: So we're creating a safe and controlled environment for our investigation. Yeah,
Speaker 1: isolated from the potentially compromised system.
Speaker 2: You got it. And by using those known good binaries,
Speaker 2: we can be confident that the results of our analysis
Speaker 2: are accurate and haven't been influenced by any external factors.
Speaker 1: Makes sense. But how do we go about getting these
Speaker 1: known good binaries? Do we just like download them from
Speaker 1: the internet.
Speaker 2: Well, you could, but that's not the most secure approach. Ideally,
Speaker 2: you'd build them yourself, which involves compiling the source code
Speaker 2: of the tools you need on a trusted system.
Speaker 1: Compiling source code. That sounds a little uh technical, maybe
Speaker 1: for someone who's just starting out in digital forensics, it
Speaker 1: can be.
Speaker 2: Yeah, but they're also pre built collections of known good
Speaker 2: binaries available from reputable sources.
Speaker 1: Oh okay.
Speaker 2: Sans Institute, for example, they offer the SIFT work Station,
Speaker 2: which is a virtual machine preloaded with a suite of
Speaker 2: forensic tools.
Speaker 1: So it's like choosing between building your own toolbox from
Speaker 1: scratch or buying a pre assembled one from a trusted supply.
Speaker 2: Exactly, And both options have their pros and cons. Building
Speaker 2: your own binaries gives you more control, you can customize it,
Speaker 2: but it requires a deeper understanding of those tools and
Speaker 2: that compilation process, right.
Speaker 1: Whereas using those pre BLOIWL binarrows is more convenient. Yeah,
Speaker 1: but then you're relying on the trustworthiness of the source exactly.
Speaker 2: So the choice really depends on your level of expertise,
Speaker 2: your budget, and the specific needs of your investigation.
Speaker 1: Okay, that makes sense. So let's say we've got our
Speaker 1: known good binaries all set ready to go. What's next,
Speaker 1: how do we actually interact with the suspect system without
Speaker 1: contaminating it.
Speaker 2: Remember netcat, that tool we talked about. It's not just
Speaker 2: for discreetly gathering data. We can also use it to
Speaker 2: create a secure communication channel between the suspect system and
Speaker 2: our forensics workstation.
Speaker 1: Oh right, right, So we're using netcat to send commands
Speaker 1: to the Suspect system and get the output back on
Speaker 1: our workstation, all without installing anything on the target machine.
Speaker 2: Exactly. It's like having a remote control for the SUSTA
Speaker 2: spec system, allowing us to perform our analysis safely, securely.
Speaker 1: These tools are so resourceful it's like we're ma guivering
Speaker 1: our way through this investigation. But speaking of resourcefulness, you
Speaker 1: mentioned that Polster's book includes scripts to automate some of
Speaker 1: these processes. How does scripting come into play during live analysis?
Speaker 2: Scripting could be a huge time saver, and it can
Speaker 2: also help reduce errors.
Speaker 1: Okay.
Speaker 2: For example, you could write a script to automate the
Speaker 2: process of collecting that volatile data from the Suspect system
Speaker 2: using netcat.
Speaker 1: Oh right, So instead of manually typing out commands, copying
Speaker 1: and pasting data, you can have a script do it
Speaker 1: all for you.
Speaker 2: Exactly. We can write scripts to gather information about running processes,
Speaker 2: network connections, open files, even capture the contents of RAM,
Speaker 2: all without leaving a trace on the system itself.
Speaker 1: So scripting makes us much more efficient and thorough in
Speaker 1: our live response.
Speaker 2: Precisely, and it's a skill that's becoming honestly increasingly important
Speaker 2: in digital forensics, as the volume and complexity of data just.
Speaker 1: Keep growing, right, it's like having a superpower. Okay, so
Speaker 1: we've gathered some initial data using our known good binaries
Speaker 1: and netcat. What are some of the key things we
Speaker 1: should be on the lookout for during this initial live
Speaker 1: response phase, like what are the red flags at scream compromise.
Speaker 2: One of the first things to check, It's simple, but important,
Speaker 2: is the system's date and time settings.
Speaker 1: Okay, date and time.
Speaker 2: Yeah. Attackers often mess with those to cover their tracks
Speaker 2: or to make it harder to correlate events.
Speaker 1: So it's like checking the clocks at a crime scene
Speaker 1: to see if they've been tampered with exactly.
Speaker 2: And you'll also want to gather info about the operating system, version,
Speaker 2: installed patches, any unusual software that might have been recently installed, right.
Speaker 1: So taking inventory, looking for signs of weakness exactly.
Speaker 2: And don't forget about network information, okay, check those network interfaces,
Speaker 2: active connections, open ports. This can help you identify any
Speaker 2: suspicious communication patterns or maybe backdoors that have been sneakily installed.
Speaker 1: It's like tracing the system's communication channels, right, Yeah, seeing
Speaker 1: who it's been talking to.
Speaker 2: You got it. You'll also want to examine the system's
Speaker 2: process list look for any unusual or suspicious programs that
Speaker 2: are running.
Speaker 1: So it's like taking a snapshot of the system's activity
Speaker 1: and then looking for anything out of place precisely.
Speaker 2: And you can use tools like ELSOF to see which
Speaker 2: files are currently opened by different processes, which can often
Speaker 2: reveal those hidden connections or data access patterns.
Speaker 1: It's like following the data trail, seeing which files are
Speaker 1: being touched and by whom precisely.
Speaker 2: And don't forget to examine the system's routing tables.
Speaker 1: Routing tables, yeah.
Speaker 2: They determine how network traffic is directed.
Speaker 1: Oh okay.
Speaker 2: Attackers often modify these to redirect traffic to their own
Speaker 2: servers or to create those sneaky back doors.
Speaker 1: It's like checking the road signs, making sure they haven't
Speaker 1: been altered to lead us astray exactly.
Speaker 2: You'll also want to check the system's list of mounted
Speaker 2: file systems that can reveal hidden partitions or external devices
Speaker 2: that might be harboring evidence.
Speaker 1: So we're making sure we're not missing any secret rooms
Speaker 1: in our digital crime scene.
Speaker 2: You got it. And finally, don't forget to examine the
Speaker 2: system's list of loaded kernel modules. These are basically extensions
Speaker 2: to the operating.
Speaker 1: Systeml kernel module.
Speaker 2: Yeah, and attackers sometimes use malicious kernel modules to hide
Speaker 2: their presence or to gain that privileged access thereafter.
Speaker 1: So it's like checking for unauthorized modifications to the heart
Speaker 1: of the operating system itself exactly.
Speaker 2: By carefully examining all these aspects of the system during
Speaker 2: our initial live response, we can start to get a
Speaker 2: clearer picture of what we're dealing with the potential incident
Speaker 2: and determine how to proceed with the investigation.
Speaker 1: Okay, that's quite a checklist. It sounds like there's a
Speaker 1: lot to consider during this initial phase.
Speaker 2: There is, But remember, the goal of live response isn't
Speaker 2: to do a full blown analysis. It's to gather enough
Speaker 2: information to assess the situation and make some smart decisions
Speaker 2: about those next steps.
Speaker 1: Right, So it's triage essentially, identify the key indicators of
Speaker 1: compromise and then figure out the scope of the incident precisely.
Speaker 2: And once we've gathered enough intel from our live response,
Speaker 2: we can then move on to the more in depth
Speaker 2: analysis of that disk image we created earlier.
Speaker 1: Okay, so let's shift gears and talk about that process.
Speaker 1: We've created our forensic image, whether we physically remove the
Speaker 1: drive or used a live Linux distribution to do it. Now,
Speaker 1: what how do we actually start digging into the contents
Speaker 1: of that image.
Speaker 2: First step got to mount the image.
Speaker 1: Mounted.
Speaker 2: That means making it accessible to our forensic tools as
Speaker 2: if it were a physical drive plugged into our workstation.
Speaker 1: Right we talked about mounting earlier. It's like virtually plugging
Speaker 1: in the hard drive to our computer exactly.
Speaker 2: But before we mount the image, remember, we need to
Speaker 2: identify its partitioning scheme that determines how the drive sliced
Speaker 2: up into those logical sections, right, like.
Speaker 1: Those C and D drives you see in Windows. But
Speaker 1: Linux it uses its own partitioning schemes, right.
Speaker 2: You got it. The most common ones are MBR that's
Speaker 2: the older scheme, and GBT, which is more modern and
Speaker 2: can handle much larger drives.
Speaker 1: Okay, so GPTI use the way to go then if
Speaker 1: we're dealing with a more modern system.
Speaker 2: Ideally, yes, but we still need to be aware of
Speaker 2: both schemes because we might encounter those older systems that
Speaker 2: are still using MBR.
Speaker 1: Right, it's like knowing both metric and imperial measurements. You
Speaker 1: need to be able to work with.
Speaker 2: Both exactly, and to identify the partitioning scheme of our
Speaker 2: disk image, we can use a tool called f disc f.
Speaker 1: Disc okay, another command line tool. It seems like Linux
Speaker 1: forensics involves a lot of command line wizardry.
Speaker 2: It does, but f disc is actually pretty straightforward. We
Speaker 2: run it on our mounted image and it tells us
Speaker 2: whether it's MBR or GPT, and it gives us info
Speaker 2: about each partition.
Speaker 1: So it's like reading the blueprint of the hard drive,
Speaker 1: seeing how it's structured, where each partition is located exactly.
Speaker 2: And once we understand the partitioning scheme, we can then
Speaker 2: mount the individual partitions that we're interested in analyzing.
Speaker 1: Okay, so we've identified the partitioning scheme using updisc and
Speaker 1: we're ready to mount the partitions. But I remember you
Speaker 1: mentioned earlier that scripting can be used to automate the process.
Speaker 1: How does that work?
Speaker 2: Well? Mounting partitions manually can be a bit tedious, especially
Speaker 2: if you're dealing with multiple partitions or complex file systems.
Speaker 2: Scripting languages like Python can really help us automate this
Speaker 2: whole process, making it way more efficient.
Speaker 1: Oh okay, so we can write these Python scripts to
Speaker 1: take care of those repetitive tasks, identifying partitions, mounting them,
Speaker 1: and even maybe performing some basic analysis.
Speaker 2: Exactly. It's like having a digital assistant taking care of
Speaker 2: all the boring stuff, freeing us up to focus on
Speaker 2: the more interesting and challenging aspects of the investigation.
Speaker 1: I can see how that would be super helpful. Scripting
Speaker 1: is like a secret weapon for digital forensics. But let's
Speaker 1: say we've mounted our partitions and now we're faced with
Speaker 1: this huge task of analyzing the data. We're talking potentially gigabytes,
Speaker 1: maybe even terabytes of information. Where do we even begin
Speaker 1: to make sense of all that?
Speaker 2: That's one of the biggest challenges in digital forensics, right
Speaker 2: the sheer volume of data we often have to deal with,
Speaker 2: and a lot of those traditional forensic tools they involve
Speaker 2: manually browsing through files and folders, which can be really
Speaker 2: time consuming, not to mention incredibly inefficient.
Speaker 1: So we need a better way, a more powerful way
Speaker 1: to search and analyze this mountain of data.
Speaker 2: Exactly, and that's where databases come into play.
Speaker 1: Databases again, I thought those were for storing like structured data,
Speaker 1: customer records, financial transactions.
Speaker 2: They are, but they can also be incredibly valuable for
Speaker 2: forensic analysis. Okay, by importing filesystem data into a database,
Speaker 2: we can use SQL queries to like really quickly search, filter,
Speaker 2: and analyze the data in ways that just aren't possible
Speaker 2: with those traditional tools.
Speaker 1: Oh okay, so it's like having this supercharged search engine
Speaker 1: for our evidence. Instead of manually digging through files, we're
Speaker 1: using SQL queries to pinpoint specific information, identify patterns, generate timelines.
Speaker 2: You got it. Imagine you're investigating a case where you
Speaker 2: suspect maybe a data breach, sensitive data way accessed, or
Speaker 2: even exfiltrate it. With the database, you could import all
Speaker 2: that relevant filesystem data, file time stamps, user log in records,
Speaker 2: network connection logs, and then use SQL queries to ask
Speaker 2: very specific questions.
Speaker 1: Like what kind of questions? Give me an example.
Speaker 2: Well, for instance, we could ask, show me all the
Speaker 2: files that were modified between these two dates, but only
Speaker 2: by users who logged in from this specific IP address.
Speaker 1: Wow, that's super specific. So we're essentially zeroing in on
Speaker 1: our search based on very precise criteria like the timeframe,
Speaker 1: user activity.
Speaker 2: Things like that decisely, and we can combine multiple criteria
Speaker 2: in our queries, making those searches, much more targeted searches
Speaker 2: that would take forever do manually.
Speaker 1: Okay, I'm definitely seeing the power of databases now. But
Speaker 1: setting them up, importing all that data that sounds pretty technical.
Speaker 2: It can be, yeah, but thankfully there are these open
Speaker 2: source database systems like my sequel that are relatively easy
Speaker 2: to set up and use, and there's tons of documentation
Speaker 2: tutorials online so you don't have to be a database
Speaker 2: expit to get started.
Speaker 1: Well, that's good to know. So databases are definitely a
Speaker 1: powerful tool to have in our digital forensics arsenal. But
Speaker 1: let's shift focus back to the analysis itself. We've talked
Speaker 1: about time stamps building timelines, but how much can we
Speaker 1: really rely on those timestamps as evidence? I mean, can
Speaker 1: we trust them completely?
Speaker 2: That's a great question. Time stamps they are super useful
Speaker 2: for establishing a chronology of events, but we always have
Speaker 2: to remember they can be manipulated by attackers.
Speaker 1: So we can't just take them at face value exactly.
Speaker 2: We need to view them as clues, not as you know,
Speaker 2: the absolute truth, and we need to be on lookout
Speaker 2: for any inconsistencies or suspicious patterns that might suggest tampering.
Speaker 1: Okay, so what are some of the red flags we
Speaker 1: should be looking for when we're analyzing timestamps.
Speaker 2: Well, timestamps that are way out of sync with other
Speaker 2: system logs or external time sources. That's a big one, right.
Speaker 1: So if a file's timestamp says it was modified at
Speaker 1: you know, three PM, but the system clock was off
Speaker 1: by an hour, that's a problem exactly.
Speaker 2: And another red flag is when time stamps are suspiciously rounded,
Speaker 2: like to the nearest minute or hour. It's a little
Speaker 2: too perfect.
Speaker 1: Usually, right, it does seem a bit too convenient.
Speaker 2: It does. And you should also watch out for identical
Speaker 2: timestamps across multiple files that were supposedly created or modified
Speaker 2: in different times.
Speaker 1: Oh okay, Yeah, it's like finding several documents on a
Speaker 1: suspect's computer that all claim to have been created at
Speaker 1: the exact same second. That's not very likely exactly.
Speaker 2: And finally, be wary of time stamps that have been
Speaker 2: altered to pre date known events or to create this
Speaker 2: false timeline of activity.
Speaker 1: So the attacker is essentially trying to rewrite history to
Speaker 1: fit their narrative.
Speaker 2: Pcisely by carefully scrutinizing those timestamps, and corroborating them with
Speaker 2: other evidence sources, we can reduce the risk of being
Speaker 2: misled by attack or deception.
Speaker 1: Okay, so timestamps useful, but handle with care. What about
Speaker 1: other techniques for establishing a timeline? Are there any other
Speaker 1: logs or records we can look at?
Speaker 2: Absolutely? One handy tool is the last command. It shows
Speaker 2: a history of user logins on the system, tells us
Speaker 2: who logged in when and from where.
Speaker 1: Oh okay, so we can see if there were any
Speaker 1: unauthorized logins or if someone logged in from a suspicious
Speaker 1: location exactly.
Speaker 2: And by analyzing the output of last alongside those other
Speaker 2: log files like WTMP and BTMP, we can create this
Speaker 2: comprehensive timeline of user activity on the system.
Speaker 1: WTP and BTP those sound familiar.
Speaker 2: We talked about them earlier.
Speaker 1: Oh that's right, that's right. WTMP stores records of successful
Speaker 1: logins and BTM stores records of those failed login attempts.
Speaker 2: You got it.
Speaker 1: So. BTMP is especially helpful for identifying like brute force
Speaker 1: attacks or other attempts to gain unauthorized access exactly.
Speaker 2: And remember, these system files can be rotated or archived,
Speaker 2: so you might need to examine multiple files to get
Speaker 2: a complete picture of that login activity.
Speaker 1: It's like piecing together a historical record from multiple.
Speaker 2: Sources precisely, and by combining information from all these different sources,
Speaker 2: we can really start to paint a much more complete
Speaker 2: picture of what happened on that compromise system.
Speaker 1: Okay, we've covered timestamps, timelines, user login records. Now I'm
Speaker 1: curious to dig a bit deeper into the filesystems themselves.
Speaker 1: What are some of the unique challenges and opportunities that
Speaker 1: Linux filesystems present for you know, a digital forensics investigator.
Speaker 2: Well, the X filesystem, which is used a lot in Linux,
Speaker 2: it's got its own specific structure and its own features
Speaker 2: that we need to be aware of. Okay, Understanding concepts
Speaker 2: like you know, inodes, data blocks, indirect blocks, that stuff.
Speaker 2: It's crucial for doing good forensic analysis.
Speaker 1: Inodes, data blocks, indirect blocks. It's like we're going down
Speaker 1: a level exploring those building blocks of the filesystem itself.
Speaker 2: Think of it this way. The inode, it's like a
Speaker 2: files identity card. Okay, it holds metadata about the file.
Speaker 2: It's time, scams, owner permissions.
Speaker 1: Size, So the inode tells us who the file belongs
Speaker 1: to when it was created or modified, and what kind
Speaker 1: of access permissions it has you got it?
Speaker 2: And the data blocks that's where the actual content of
Speaker 2: the file is stored.
Speaker 1: Okay, so we're trying to say, recover a deleted file,
Speaker 1: we need to find both the inode and the data
Speaker 1: blocks exactly.
Speaker 2: And within the excale system there are also these features
Speaker 2: like extended attributes and access control lists. They can be
Speaker 2: used to store additional information about.
Speaker 1: Those files, additional information what kind of information it could be,
Speaker 1: anything really, from security settings to user defined data.
Speaker 2: And sometimes attackers, those crafty attackers, they exploit these features
Speaker 2: to hide data, to hide malicious code.
Speaker 1: Oh sneak.
Speaker 2: It makes it harder for us to find what we're
Speaker 2: looking for. It's like playing hide and seek, right. And
Speaker 2: as file systems evolve, they introduce new features.
Speaker 1: Like extens extense.
Speaker 2: Yeah, they're more efficient way to manage those large files,
Speaker 2: but they can also be more complex to analyze from
Speaker 2: a forensic perspective.
Speaker 1: So the landscape is constantly evolving, presenting new challenges for
Speaker 1: both the attackers and the investigators exactly.
Speaker 2: And that's one of the things that keeps digital forensics
Speaker 2: so interesting. Yeah, it's a constant learning process. There's always
Speaker 2: something new to discover, new techniques to learn.
Speaker 1: Well, speaking of new discoveries in that fills awesome stuff case.
Speaker 2: Yeah, how did.
Speaker 1: Polstra use his knowledge of the x file system to
Speaker 1: actually uncover evidence of the attack?
Speaker 2: He used a few different techniques. One was analyzing a
Speaker 2: RAM dump with volatility.
Speaker 1: Volatility, didn't we talk about that earlier when we were
Speaker 1: discussing live analysis I did.
Speaker 2: Volatility is a powerful tool. It lets us analyze the
Speaker 2: contents of RAM even after the system has been powered off.
Speaker 2: In this case, he used it to uncover hidden processes
Speaker 2: and files that weren't showing up in the regular filesystem analysis.
Speaker 1: So it's like we're using x ray vision to peer
Speaker 1: beneath the surface of the operating system exactly.
Speaker 2: And he also used network traffic analysis uh huh to
Speaker 2: track the attacker's movements, uncovered some suspicious connections, maybe even backdoors.
Speaker 1: So volatility was helping him see what was happening on
Speaker 1: the system itself. And then network traffic analysis showed how
Speaker 1: the the attacker was interacting with the outside world precisely.
Speaker 2: And by putting those two together, Polster was able to
Speaker 2: create a compelling narrative of the attack led to the
Speaker 2: identification and the capture of the culprit.
Speaker 1: Wow. Impressive work. Okay, so we've covered a lot of
Speaker 1: ground in the steep dive. We've talked about the importance
Speaker 1: of preserving evidence, those key steps and live response, the
Speaker 1: power of scripting and databases, and the challenges of timeline
Speaker 1: analysis and filesystem forensics. What else is there anything else
Speaker 1: you want to share before we move on to the
Speaker 1: final part of our investigation.
Speaker 2: Well, there's a whole world of you know, more advanced technique,
Speaker 2: specialized tools. We haven't even scratched the surface. Oh yeah,
Speaker 2: But I think the most important takeaway, the thing I
Speaker 2: really want to emphasize is that Linitz forensics it's not
Speaker 2: just about technical skills. It's also about mindset, minds.
Speaker 1: Okay, what do you mean by that.
Speaker 2: It's about being curious, skeptical, methodical. It's about approaching each
Speaker 2: investigation with an open mind, you know, being willing to
Speaker 2: challenge your assumptions, always be on the lookout those subtle
Speaker 2: clues that might lead you to the truth.
Speaker 1: So it's like you've got to be a digital detective,
Speaker 1: constantly piecing together the puzzle, one clue at a time,
Speaker 1: exactly and.
Speaker 2: With the right tools, the right techniques, and the right mindset,
Speaker 2: well you can uncover even the most cleverly hidden digital crimes.
Speaker 1: Well said, But before we get too carried away with
Speaker 1: our detective work, let's take a quick moment to recap
Speaker 1: some key takeaways from this second part of our investigation.
Speaker 1: What really stood out to you as particularly interesting or
Speaker 1: unexpected in this section?
Speaker 2: For me, it was definitely the idea of using databases
Speaker 2: for forensic analysis. It just clicked. Why spend hours sifting
Speaker 2: through files manually when you can have the computer do
Speaker 2: the heavy lifting for you.
Speaker 1: Right, It's like it's a total game changer, and it
Speaker 1: shows how digital forensics is always evolving, always borrowing techniques
Speaker 1: from other fields and adapting them to the unique challenges
Speaker 1: of you know, cybercrime investigation exactly.
Speaker 2: So, it's not enough to just be a tech wizy days.
Speaker 2: You also need to be a bit of a database guru,
Speaker 2: a scripting ninja, and maybe even a psychologist to understand
Speaker 2: how these attackers think and operate. It's true, and speaking
Speaker 2: of attackers, one of the things that never ceases to
Speaker 2: amaze me is how they're always finding new ways to
Speaker 2: cover their tracks to obfuscate their code. It's a constant challenge.
Speaker 1: Yeah, it's like a never ending arms race with both
Speaker 1: sides constantly upping their game. You mentioned earlier, there's a
Speaker 1: whole whirl of advanced techniques and tools that we haven't
Speaker 1: even touched on.
Speaker 2: Oh, we barely scratch the surface.
Speaker 1: Can you give us a little glimpse into what lies
Speaker 1: beyond the basics?
Speaker 2: Sure. One area that's becoming increasingly important is file hashing.
Speaker 2: It's a technique that lets us identify known good or
Speaker 2: bad files by comparing their unique digital fingerprints against massive databases.
Speaker 1: Okay, so it's like a fingerprint database, but for files.
Speaker 1: We can quickly flag suspicious ones or verify the integrity
Speaker 1: of files we know are good.
Speaker 2: Exactly, and this is especially useful when you're dealing with
Speaker 2: huge amounts of data.
Speaker 1: Oh I bet what else?
Speaker 2: Then there's the world of reverse engineering, where we use
Speaker 2: tools like obs, dumps, strays, GDB, all kinds of tools
Speaker 2: to dissect malicious code and understand how it behaves.
Speaker 1: So we're taking apart the attackers tools, figuring out how
Speaker 1: they work and what they were designed to do. That
Speaker 1: sounds pretty advanced, though, do you need to be like
Speaker 1: a coding expert for that.
Speaker 2: It definitely helps to have a solid understanding of programming concepts.
Speaker 2: But there are resources out there to help investigators get
Speaker 2: up to speed with reverse engineering techniques and the insights
Speaker 2: you gain from analyzing malicious code. Those can be incredibly
Speaker 2: valuable in understanding the attackers motives, their methods, their capabilities.
Speaker 1: It's like getting inside the mind of the criminal exactly.
Speaker 2: The more we understand how attackers operate, the better we
Speaker 2: could defend against them.
Speaker 1: Makes sense, So file hashing, reverse engineering just a couple
Speaker 1: of examples of those advanced techniques using Linux forensics. But
Speaker 1: where can someone go to learn more about this stuff?
Speaker 1: Any resources you'd.
Speaker 2: Recommend absolutely online communities like Reddit, specialized forums. Those are
Speaker 2: great places to connect with other enthusiasts and experts. You
Speaker 2: could share knowledge, ask questions, get help. Sans Institute they
Speaker 2: offer excellent training courses and certifications in digital forensics covering
Speaker 2: both Windows and Linux environments.
Speaker 1: So it's like joining a global network of digital detectives
Speaker 1: all working together to fight cybercrime.
Speaker 2: That's a great way to put it. And the thing
Speaker 2: about the digital forensics community is people are so willing
Speaker 2: to share their knowledge, help each other out. It's very collaborative.
Speaker 1: That's fantastic. So for anyone listening who's thinking about, you know,
Speaker 1: diving deeper into this world, there are definitely resources out
Speaker 1: there to help you get.
Speaker 2: Started, absolutely, and I think the most important thing is
Speaker 2: to just stay curious, keep learning, and never be afraid
Speaker 2: to ask questions.
Speaker 1: Well said, this deep dive has been an incredible journey
Speaker 1: into the world of Linux forensics. I have to admit
Speaker 1: I'm feeling pretty inspired to put on my digital detective
Speaker 1: hat and start solving some cyber mysteries myself.
Speaker 2: That's the spirit.
Speaker 1: And remember the skills you learn in digital forensics, they're
Speaker 1: not just applicable to investigating cybercrime, right, they can also
Speaker 1: be valuable for incident response, data recovery. Oh absolutely, even
Speaker 1: just you know, understanding how computer systems work at a
Speaker 1: much deeper level.
Speaker 2: It's all connected.
Speaker 1: So it's not just about catching the bad guys. It's
Speaker 1: about really understanding the digital world around us and using
Speaker 1: that knowledge to make it a safer, more secure place
Speaker 1: for everyone.
Speaker 2: Goodness said it better myself, and.
Speaker 1: Who knows, maybe one day you'll be the one writing
Speaker 1: the next great book on Linux forensics. Sharing your knowledge
Speaker 1: and inspiring others to join this amazing field.
Speaker 2: Maybe you will. You seem to have an act for it.
Speaker 1: Well. On that note, I think it's time to wrap
Speaker 1: up our deep dive for today, but before we go,
Speaker 1: any final words of wisdom for our listeners who are
Speaker 1: eager to continue their digital detective journey.
Speaker 2: Remember, knowledge is power, but it also comes with responsibility.
Speaker 2: Use those skills you'll learn ethically, responsibly, and always strive
Speaker 2: to make the digital world a safer place for everyone.
Speaker 1: Well said, and be sure to check the show notes
Speaker 1: for links to all those resources we mentioned today. Until
Speaker 1: next time, happy investigating,