From Pre-Law to FLARE: How Josh Stroschein Became Google's Malware Analyst

Speaker A: I tried creating a defang tool and I went round and round on how to create it. And I finally settled at. I'm going to, um, redirect the entry point to a little blob of shellcode that pops up with a message box and says, are you sure you want to run this? Yes. Okay. Cancel.

Speaker B: No.

Speaker A: And it worked pretty good. I actually just added a new section in the PE file only added a new section, made it read, write, execute, patched the entry point to the shellcode, had the shellcode patched to the original entry point. If they chose to click ok. Then I dealt with TLS callbacks. In the rare case that something had TLS callbacks. Everything was going pretty good until I got to net binaries. And for whatever reasons, the net, even though it's still a PE file, I just was running into issues, figuring out how to add the proper space for these things. Um, and it became a nightmare.

Speaker C: Simply Defensive brings you the industry's top practitioners, innovators, and leaders to inform, inform, educate and entertain. Join us as we unlock the secrets of defensive cyber security. Hello and welcome to the latest episode of Simply Defensive. I'm Josh Mason, and with me, as always, my good friend and co host, Wade Wells.

Speaker B: Good afternoon. I believe maybe we don't know when this is airing now. Yeah.

Speaker C: Or good morning, good evening, whichever, Whenever you're watching, listening to this. And today we've got with us, Josh Shosheim. Josh, uh, thanks for being on the show with us.

Speaker A: Yeah, thanks for the invite. I don't often get to be a guest, so it's. I'm looking forward to it.

Speaker C: Yeah. You've got your own podcast.

Speaker A: Yeah, yeah.

Speaker C: And then, uh, you've, uh. Now Jerry goes by Dr. Gerald Ozier, PhD. And you all. Weren't you classmates at Dakota State or.

Speaker A: Oh, no, I was. He was in. So I taught. He was in. He took some of my classes. I was teaching.

Speaker C: Oh, okay.

Speaker A: So I think he was. If I was the first cohort to go through the PhD program, it was a Doctor of Science for one year, and that's when I went through it, and then it became a PhD. He was probably the cohort or two after me, but then I was teaching there at the same time, so I was going through the program because I was teaching there and I needed to get terminal degrees so that I could get onto a tenure track and make some real progress in academia.

Speaker C: Yeah. Yeah. Nice.

Speaker A: And now here I am at Google. So I guess I made too much progress. I don't know how to look at

Speaker C: that, yeah, you're too successful at being a professor brought you back into.

Speaker A: Yeah, yeah. So we got to know each other quite well through the coursework. I believe he took a class or two. I taught a number of the, like the 800 levels, the PhD core, there was a malware analysis, uh, reverse engineering, I think there's an exploitation course. And I taught all of them at one point. I don't remember if Jerry was in any of those or not. I know he shadowed one of the courses I taught in our master's program, a software exploitation reverse engineering course. And then just the number of times in the program, students have to come to campus three times. Jerry just really Jerry, he became a known entity quick. He's so high energy. And we just got to know each other throughout the years and, and just been crossing paths and bumping courses ever since.

Speaker C: Nice. Very nice. Now you've run the gamut all the way to Dr. Science in Cybersecurity teaching and then now doing reverse engineering, running at Google and doing podcasting. But you're. You don't have a uh, traditional quote unquote, traditional cyber security background like a lot of people think about, do you? You were. Did you do development before?

Speaker A: Yeah, so I. Cyber security. I'd say in a way I have had a fairly non standard career. I went to college, um, was going to do pre law, was in pre law. I finished criminal justice degree. But I also was doing computer science because I had a, an interest from childhood. I was lucky enough. I grew up on a farm, but we always had a computer. I'm not really sure why, but we did. I felt lucky having one available. I went into pilot training for the military. I got in the Guard about. Oh, When I was 20, I think I got on my 20th birthday. I enlisted and thought I want to be a pilot because it's. I guess that's just what you do when you get in the Guard. But I did get selected. So I finished college. I went to a couple years of pilot training. It was another train wreck. I still, I uh, still have nightmares about it. It just wasn't for me. I made it quite far enough to know that. Now looking back, I'm glad it didn't work out. I came back from that a wrecked man, not sure what to do. And I started. I found a job doing a bunch of net development at a credit card processing company. And it was at that point, about a year into it, I'd actually been doing some consulting work. As an undergrad I got into some real basic web Development for some people in the area, which was at the time, it was exciting because I was going from very static HTML to doing kind of the full scope with the lamp stack and phpmiSQL. But when I got into the credit card processing, then I saw, uh, after about. I don't remember how, a few months there, I was asked to help see if we were writing code securely. And that got me on the path of owasp and I started really picking up, uh, an interest in security then. So at some point I went back and finished a Master's in Information Assurance, which loosely mapped to the cisp. And. And then I stayed traditional software engineering with kind of a slant on application security for many years. And it wasn't until I got to teaching in Dakota State, my workload was malware analysis and reverse engineering that I really got into those areas. Um, and from there it just took off. It said I never would have expected to be where I'm at today doing reverse engineering.

Speaker B: So you taught it and then you actually got a job in it is pretty much what happened.

Speaker A: Yeah, yeah, I taught it. I went and took a. Funny enough, I took a course at Black Hat. It was the Mandiant Flare Advanced RE course.

Speaker B: Oh yeah.

Speaker A: Realized I didn't know anything. I forgot, forgot all the assembly that I learned 15 years prior. Um, and then I just. A couple of happy connections came along. I got to know someone in the PhD program, Jared DeMott. Jared and I just connected. He came to campus a couple times and taught some courses during Dakota Con, which is kind of like a B sides on campus. That turned into me teaching some of his classes because he was a Black Hat instructor and did derbycon and a bunch of other places. He was also at Bromium at the time. So I was able to pick up an internship one summer at Bromium. And they had really cool tech. It was a micro virtualization. So it was the heyday of the exploit kit. And what would happen is the users would launch a browser, but the browser would be in what they called a micro vm. So when they stumbled across an exploit kit or they clicked a link from an email, what was really neat about it is not only then was it isolated, but it was like a little sandbox. And so you could allow the thing to run the exploit to maybe trigger, get some good behavioral data, and then it could report back to a dashboard. And then the micro VM would close and the user could be notified that, hey, Romium saved the day again. Uh, yeah. And then from there I just kind of Hopped and skipped around a little bit. I was at the OISF working with the Suricata, the foundation that supports Suricata. Wanted to learn the ins and outs of network security a little bit more and well, uh, at some point I got into doing some YouTube stuff and just trickling content onto my channel around reverse engineering and. And then one day out of the blue Google called I think got a LinkedIn invitation and um, went through that whole process of applying actually what happened twice. Uh, I got an invitation to apply in 2020, got an offer but it required a move to Mountain View and I live in the Midwest so it was a pretty big change in cost of living and many other things and decided to after much anguish to turn it down. And then three years later another opportunity came up. Went through the whole interview process again and was able to join with the Uppercase team, which is Chronicle. And then mandate got acquired that brought flare in and about a year after joining I was moved over to the flare team. Ah yeah.

Speaker B: So the flare. I don't know it is but I think like one of the first blog posts I ever wrote was how to build a flare VM pretty. So that's been. Been a staple projects. Yeah, I've been a staple in my toolbox since probably like I can remember being able to actually do things rather than just being a SOC analyst and closing alerts, having one of those VMs on my. On um, somewhere and then going all the way through it and then the actual flare ctf. Right. Flare on is you one of the probably better CTFs out there if you're really looking to have some fun. I've ran through it a couple times. It's always. It's taken my knowledge to like the next level because that is not where I go at all. I just read logs all day.

Speaker A: Yeah it's. I don't know when this will air but Flareon 12 is occurring now and uh, it's I guess the 12th iteration. So hopefully it's survived so far the acquisition and hopefully Flareon 12 or 13 will be there next year. And uh, yeah, I mean it's. It's a little different I guess every year because every year it's the different. Slightly different set of challenge development but the premise is the same sequential find the email, reverse engineering. Usually when you look at the stats from year to year, I think typically a pretty good. If you base your interpretation of how challenging it was on number of solves, it seems to filter down to smaller and smaller numbers all the way to the last Challenge. Um, but then you get some pretty crazy. I think this year, last I looked at the scoreboard, the first person to finish was just a little over a day. So I know if you can go without sleep and you just live this stuff and your brain works in ways that I probably can't imagine, that's pretty awesome.

Speaker B: I gotta do that.

Speaker A: Yeah, yeah, it's neat. I think one of the first, uh, uh, one of the. I probably the first time I really got into a CTF too was it was flare on um, years and years ago. And I really liked it. But the thing I didn't like about it being in academia was that when you got stuck and if you weren't able to get yourself unstuck, the learning stopped. And so I did end up using uh, ctfs a lot in my classes for final exams and stuff. And actually at one point had a student help me write a CTF framework. I'm pretty sure it's still out there on GitHub. And we just tweaked the scoring system a little bit so that I could put hints and the hints. The students could purchase the hints at a cost of their final score. So yeah, my thought is, uh, you'd probably rather get an 86 than an 89 or an 86 than a 91 and get through more of the challenge and purchase these hints than just get hard stuck and not know where to go. Um, I'm sure platforms have evolved. Ctfd I think is still a pretty dominant CTF platform for classic. Yeah, I think they do all that now, but I don't think they did at the time. Which is why we went after and tried to create something that was a little bit more, I always thought a little more educational.

Speaker B: Yeah.

Speaker A: A little less competitive.

Speaker B: Especially if you're. The hints to um. It always just reminds like the certain CTFs that when you take a hint that like it lowers your score but the hints to lower your grade, I would be, I would not like. I would just keep going. I would like search and Google everything, figure out what to do. If it was a closed book, I'd be screwed.

Speaker A: But yeah, I was always pretty generous. They uh, were small, small deductions and.

Speaker B: Oh yeah.

Speaker C: And stuff. So I was between the A plus and the, you know, high A. Yeah, yeah, absolutely. I feel that.

Speaker A: Yeah. And then it gets folks, students, especially undergrads into that introduces them to that reverse or the capture the flag scene. That's a whole thing with defcon every year and just.

Speaker C: Oh yeah.

Speaker A: How serious and competitive folks are. Yeah, it's fun.

Speaker C: Uh, there's so many leagues now.

Speaker A: Yeah, yeah. To get them introduced at an early age and. Or earlier in their career and as a tool to learn.

Speaker B: And I think flare was like, one of the first ones that I considered a more like blue teamer esque as well. Right. There's a little bit of everything in it with reverse engineering, but there was stuff that, like, I had to do actually in work. And it wasn't until, like, I saw like, Boss of the Sock, where I'm like, okay, this is actually what I do. But sure, okay. Yeah. But that's the one thing I enjoyed because I wasn't the guy that was like popping shells. Right. And getting root all the time. So I wanted something a little bit different.

Speaker A: Uh, yeah, yeah.

Speaker C: That's always an interesting one with reversing because I think there's the two aspects of reverse engineering and we talked with Hammond about that a little bit.

Speaker B: The.

Speaker C: A lot of people look at reverse engineering as an offensive thing and it ties into, like, it's touched and taught in, like, the upper level offensive security courses for then building malware and because you reversing something in order to then be able to exploit it. But what I'm sure a lot of what you do, and I know a lot of what I've seen on, like, your videos and on Hammond's videos, a lot of the reversing is reversing malware in order to then create, like, figure out what, how to stop it or how to detect it, things along those lines. And yeah, that's, to me, that's defensive security, blue team, um, all the way. But I don't know.

Speaker B: I don't think a reverse engineering is red. Like, I, I get where you're coming from, but I have never thought of it that way. I've always thought it was more of a blue thing, but I could understand it coming that direction.

Speaker A: Yeah, yeah, I've always seen it kind of both directions. I think a lot of times. A lot of times we are reversing for defensive purposes, to help generate yara, to help get good ids, sigs, to understand capabilities and can you defeat the ransomware crypto and recover files and that kind of stuff. We've got teams that are offensive. There's a number of companies that do that. They're just simply out there looking for vulnerabilities, trying to figure out CVEs before they become CVEs. And, um, of course, when you look at malware, you learn a lot from what malware authors are doing. And I think that can become kind of a cyclical learning process to you find the techniques you understand when you look at enough of it to get new and novel and, and then to turn around. And I think you could feed a red team, I think if you had a, I guess an organization that has a healthy, both of these teams, looking at them from all these different perspectives, I think it could probably feed each other. But I think a lot of folks do see the RE portion of it to be uh, probably more blue teamish and defensive in nature. There's not a lot of, I don't know how many res are out there. The team I work on happens to be probably one of the largest teams oh in the world, but certainly one of the largest teams I know of. It seems like teams, people that are doing re, it's just part uh, of their job, an additional duty. It's not the sole focus of what they're there to do. They have other obligations. They do more threat intel stuff or more SOC stuff and every once in a while they get a chance to really dig deep into something or build a config extractor, do some more long term prolonged research. So yeah, I guess I don't know how many, you know, what everybody's out there reversing for.

Speaker C: That's something I've always wondered about. How many of you all are there?

Speaker B: No, I don't. I. The only people I think who are really reverse engineering are the big tech or the managed security provider. The security providers. Right. Like I worked at Fortune, uh, five companies and stuff like that. Where we didn't have like where there's a couple of us who could probably, you could throw it into Ghidra or something and we could poke around and do stuff. But at the end of the day most of those larger companies are just going to pay Google or well, pay Mandiant in order to go do that for them or they have some type of retainer that's going to do it for them because the reverse engineering is just so specialized.

Speaker C: Is it reasonable that like what Marcus, John Hammond and you are probably like the representative public face of how many reverse engineers there are in the industry.

Speaker A: Yeah, I don't know, like the ice

Speaker C: tip of the iceberg that like people see of like how many spots there are available.

Speaker A: Yeah, I think you're probably right. And, and, or although I need to figure out how to get my YouTube numbers up like John's because some days I tell myself it's okay. You're talking about nerdy reverse Engineering, ultra niche. Same with the podcast. You're in this ultra niche area, even within cybersecurity. So it's okay.

Speaker C: But.

Speaker A: But he's certainly doing something right. But yeah, I think it definitely. There's just a smaller. I get asked a lot, how do I get into reversing, how do I find a career, how do I find a job? And I mentioned it earlier, but I just, I couldn't have been more, more fortunate if I couldn't have picked this career path even if I wanted to because there's no way I could have planned for it to be where I'm at. And even being on the Flare team, that just happened. I happened to join Google before they acquired Mandiant and then they acquired Mandiant and now I'm on this team.

Speaker B: So I was at Mandiant before they were acquired by Google. We almost worked together.

Speaker A: Yeah, I saw. It just, is all. It just happened. There's that element of I think being prepared, building a good network and then there's just a healthy dose of right place at the right time. Call it luck, call it whatever you want. But yeah, definitely it's a small, it's a small community and it's pretty um. There just, there isn't a lot. I do not come across a lot of folks that are like, I'm full time re at my company. It's a lot of times it's, I'm doing it as unneeded or on demand or I'll do a little bit of triage and then we'll kick it to a, uh, contract or something that we have. I think that's pretty common. And, and that's what I tell folks. You don't uh, necessarily need to get right into re. You can, if you want it, you can, uh, you will find it. You have to work hard for it. You have to be patient, you have to network and do all the right things. But like, there's a lot of other paths to get there that are going to be really beneficial and grow your career. And because the odd thing is once you. Now that I'm at a point where I'm getting able to do it full time, it's kind of limiting. There's uh, only like the career movement. I have to be able to tack on other skills and, and spend some time. I'm taking courses on LLMs and AI and data sciences and all that kind of stuff to, to add a little bit more mobility to myself and kind of decide where I want to be, do I want to stay independent Contractor and be very technical. Do I want to try to get into some more of a management role? Both of them are going to require a broad set of technical skills and so interesting.

Speaker B: I feel like reversers are definitely like, when you were coming up as like a soc analyst, it's one of those jobs that you look up as like the shining stars of getting out of the soccer. Like you're. It's like digital forensics sometimes ir and then even further, it's like reverse engineering. You're like, yeah, like one day I'll be doing that and not have to sit here and looking at the queue all day. Uh, that's what I remember it as. Doing flare.

Speaker A: We have cues.

Speaker C: Yeah.

Speaker B: Okay.

Speaker A: I won't say any more than that, but we have cues. Yeah. When I started at the credit card processing company, it was a great place to start and I learned a ton. It was eye opening, going from doing college coursework as my formative introduction to computer science and formal programming to seeing what people were doing in the real world. And, um, that as I started digging into security, you just realized how little, at least in that application folks were really thinking about it. It was just such an afterthought. And this is early, early 2000s, I suppose, still 2007 or so. It's just changed a lot. And I had a different point to all of that and I completely lost it. So I'm going to blame Friday afternoon on that and it'll come back to me and I'll just jump in and start talking about it again.

Speaker B: Filming, maybe. Maybe we should black out Fridays, because I feel like filming on the end day of a Friday definitely is like a little brutal.

Speaker A: Yeah, no, it's just a little more. A little bit more of a Friday for me than usual. Yeah, but it's been a good. It's been. Definitely been a good crap. I think the. The challenge of it, it's just when I first started getting into reverse engineering, I saw opportunity in academia. We had a course in reverse engineering. Undergraduate and then graduate and doing PhD. And I thought, oh, we're having a really hard time filling this. Maybe this would give me a little bit of career stability. And then the internship happened and I just decided I really want to prove to myself I can do it. And then I found it to be. I didn't really appreciate it at the time, but the being forced to learn it and teach it simultaneously. I'm sure a lot of my students that first semester were like, man, this guy doesn't know what the hell he's talking about.

Speaker C: But they don't know. They never know.

Speaker A: I don't. Yeah, I probably was able to stay one. Just enough a, uh, step ahead. There's probably. Sometimes it was a half a step and there's probably a couple that probably knew more than I did. But it really. I had to learn it. I had to not only learn it, but go and then get in front of a room of students and teach it. And I think that's what I like about YouTube. A lot of times when I'm picking content, I'm not chasing headlines. I'm not even worried about juicing the algorithm. It's just. But before the podcast, I was looking at them. I just wanted to get a little bit deeper into EDRs. And so, um, I think Open EDR is probably the only one that's open. So I'll just take a look at this. Looking at the driver components, looking at how it figures out which process that it's going to inject the DLL to into. Looking at the DLL injection process, looking at how it actually does the hooking, just the whole evasion, that's where ultimately I'm getting. And then as I do that, I think this is. If I have to go through the process of learning it, if I turn around and make some content to share with anyone, it just helps me solidify what I've learned and then hopefully somebody else benefits from it. Yeah, I guess it's just become a big part of my, uh, my, my process. And I find that the, some of the concepts are just. There's so much. It's just. There's so many different little areas and things that you have to know. And I've only ever really focused on Windows. I think other operating systems are going to be similar, other architectures are similar conceptually file formats. But there's just so much. And I just, I don't know. I hope I developed a knack of trying, um, making those complex topics a little bit easier to understand.

Speaker B: I know. Imagine you get this like, re interview job. You're going through all through it and then at the very end of the interview the guy's, yeah, we're a complete Mac shop. And you're just like, I could do it, but it's going to require a lot of learning.

Speaker A: Yeah. Yeah. Ah, yeah. And Max are. That's another thing that's on my, on my list of things I'd like to explore a little bit more. And I don't. I haven't had an occasion to really dig into Macs, although I have a story. It's going to be in my podcast later this month. Was at Black Hat this summer and teaching a course, and we had an infected Mac actually in the classroom, and the Black Hat not came in. And at first they thought it was my Mac. There's only two Macs in the room. They're like, Is there Josh's MacBook Pro here? I'm like, yeah, I'm Josh. I'll let you guess which one. And it was. It was. They gave me a report and it was the, I think Amos Stealer or Atomic stealer. It's kind of the popular Mac info stealer right now. Yeah. So I started digging around. I don't have any indicators. None of the stuff is lining up here. It's. There's. The binary's not running, the network communication's not there. Um, later that afternoon, I went back. I was on my way to the noc and they were on their way to me and they're like, yeah, we made a mistake with the host name. It's the other Mac. And then we took a look at that Mac and sure enough, there it was. Beacon in and running and going how they.

Speaker B: I'm. I am thoroughly impressed that they're doing that level of security on, uh, their public WI fi.

Speaker A: Yeah, I was too. In fact, that's why we made a podcast out of it. Because I'm like, I am. I'm surprised that you are. The Black cat cares enough to not. I knew they would care enough to monitor networks, but I didn't think that they would be proactive about telling attendees. Yeah. About injected. Yeah.

Speaker B: It's like logging on to guest WI fi and expecting, like, you're at Starbucks on their guest WI fi and all of a sudden you get in the Starbucks phone rings and it's for you

Speaker C: going to, like, the Black Hat. It's intense like it is. There's a lot of folks in there, like.

Speaker A: Yeah.

Speaker C: All day. Um, and they've got a lot going on in there.

Speaker B: Dude. Can you tell us how, like, seriously, how do they catch it then? Just. It has to be network telemetry or.

Speaker A: Yeah, I think this one, this one was beaconing because. So once it infected it. It was. And it was. I don't know if the primary binary was just running and it was beaconing and it was a. A consistent beacon to a. Just a dotted quad IPv4 address. So, uh, stuck out that. Why would something be beaconing directly to an ip and.

Speaker B: Yeah, like poor malware.

Speaker A: Yeah. And then it was HTTP. So once the beaconing was detected. Yeah. Then they looked at the HTTP and the query path structure was in the kind of. The check in pattern matched some open source reporting and I don't think IDS alert fired on it. It didn't sound like an IDS alert fired on it.

Speaker B: So now you probably get some type of Rita.

Speaker C: Uh.

Speaker B: Right. Black Hills is C2 beginning mechanism and then you can see it all.

Speaker A: Yeah.

Speaker B: And I wouldn't be surprised since it's that small of a conference. They have actual packet captures that they can then go look at. Yeah, that's. I'm still only capturing for two weeks. Imagine how many false positives there would be there though. Right. That's the impressive because there is going to be crazy stuff running that's expected

Speaker C: but for like the couple days that it's the classes. It's. You've got a few hundred people with laptops. They've got 30 people in that knock 30 people to a few hundred students. Like it's not that hard to do.

Speaker B: Yeah. But they're also thinking about everyone else on the WI fi. Right. Think all the sales people. Like those are. Honestly those are the. Usually the people are going to be infected.

Speaker A: Uh, yeah.

Speaker B: Or X filling.

Speaker C: True. But also like your students are probably the ones who are going to have malware.

Speaker B: Yeah. Yeah. But they're also gonna have like legitimate malware.

Speaker C: Yeah.

Speaker B: Do you have to submit all your malware samples before you teach?

Speaker A: Yeah. No.

Speaker C: And that's not necessarily.

Speaker A: I, you're uh. Right. That's. It's. I think it's impressive that they're really putting the effort to try to discern and figure it out and they use the context to say okay, 17 people in this classroom just do all the same thing. Okay. It's probably uh, an exercise or a lab one.

Speaker B: Yeah, that's a good point. Yeah.

Speaker A: Now it stands out a little bit more. And uh, they don't know what any class is doing until things start happening.

Speaker B: Probably.

Speaker C: Uh, they also showed up to triage it like manually rather than just oh, now you can't connect.

Speaker A: Yeah. Also, you know, that would have been another thing. It just like boot the person off the network and leave them hanging. And it was.

Speaker C: Maybe it's benign. Maybe it's just made to look that way because it is part of the class.

Speaker B: Uh, yeah. It looks good. Right. That person will never forget this. Maybe like CEO of some big companies now sending all of his workers to Black Hat just to check if they have malware on their computers.

Speaker A: Yeah. It only costs you the one with just the two day training, it's cheaper than the four days. Yeah, yeah. I was also. That was really cool.

Speaker C: Also the hard part about creating training for uh, cybersecurity. Yeah. You want someone to look at real malware. Like how do they do that safely?

Speaker A: Yeah, yeah, it is. And that's another thing I've looked into over the years is how do you, like, how do you, what do you do? Do you just use the real stuff? I tend to just use the real stuff.

Speaker B: Yeah.

Speaker A: What we do you defang? It depends like how much what are you trying to defang? Is it easy? Is it easy if it's just a, an uh, info stealer can neuter or change how it's connecting out or something more destructive or it's wrapped in massive layers of obfuscation. It's quite a bit more challenging. You know, the alternative is to make your own, which I would have said up until recent that's really time consuming. I, I mentioned I teach in a class this fall and I've been able to use AI to help create a lot of full malware things that I know what I'm exactly what I need it to do. I just, it take. It would have taken me a lot longer to do it had I not been able to get Gemini or Grok or something to help spit it out.

Speaker B: And I'm impressed that they actually spit stuff out that revolved around that. Like your queries are very careful. Write me a function that does this and then write me another function that does this.

Speaker A: Yeah, I actually was a little surprised too. Gemini was initially the one that was the holdout and it's like, ah, you're up to no good. I'm not going to help you. Grox not going to care. Sure enough, Grok did uh, um, but I got it to work. I'm teaching a lab right now. We're doing basics or runtime linking. And so I'm like, I want a function that resolves a bunch of APIs from uh, after it loads two modules and I want to Xor all of the strings and then have a function to decrypt those right before they're used and then creates basically which is the reverse shell. So it creates process and then it maps the handles, the standard handles from the process to uh, the socket and. But it just, it all did it in C. I didn't have to mess around too much. Had a little bit of fine tuning here and there and, and then yeah, I got that done and I'm like, that was too easy. Let's change the port based off of the day that it connects to.

Speaker B: Oh, my God.

Speaker A: Let's add some arbitrary arithmetic to make key recovery, because it's meant to be a debugging lab. So let's just make it the key. The single byte key. Ridiculous to try to recover it unless you just debug it. So, like, trying to force them to not go down a static route, go down a. Go down the debugger route and just look at the return value or look at the byte value passed to the XOR function or something that doesn't require static analysis. But it did really good. I'm really.

Speaker C: Wait. Nightmares? No.

Speaker B: No. So in, um. In my master's course, in my. One of my master's courses, they actually gave us. You had to go off, do stuff, and then if you did it right, you found a piece of malware. And then me being actually, like, already, like, pretty tenured in cybersecurity, I found the malware. I started reverse engineering it's. And I realized I'm like, hey, this piece of malware is, like, all broken. Like, there's no way this is legit. And then using strings in the malware, I found the real piece of malware and then continued to write my report based off that malware. And then, like, I hit up the professor. I'm like, hey, man, you're like, labs broken. If you're gonna give us something, at least tell us you defanged it so I don't have to go off and find open source. A report. And then I slap my report down. He's like, all right, that's a good call. And I should have told you guys it was broken and that you couldn't have done anything with it. I'm like, yeah, but that, uh, that course, that was. It was an IR course, and I was just very upset the entire course because I was doing ir. I was like, this is wrong. Uh, man.

Speaker A: Yeah. Yeah, it's.

Speaker C: It's.

Speaker A: I don't know.

Speaker C: I don't know.

Speaker B: I know. I appreciate.

Speaker A: Go back and forth you going that.

Speaker B: You going that hardcore into a class. Like, it makes me feel bad because my masters, the security was a joke. Like, the classes were like. It was just. I got a degree, I didn't really learn much. But hearing, like, the stuff you're teaching, I'm like, maybe I should have went somewhere else and actually learned stuff during my master's program.

Speaker A: Yeah. Yeah. I don't know. We'll see how the semester goes. But I just. Yeah, I look at it and And I guess that's the other thing, the, the benefit of having been doing it ARI kind of stuff for a few years and I can look back and I guess a lot of the content I create is this is stuff I wish I would have known. It's either it interests me for some reason or it's stuff I wish I would have known when I got started. Even though we've been people have been reversing in a formal fashion as a profession for several decade or two now, it's still hard to find all the information and know where to start. And yeah, I still, there's still I think a shock of, of just getting used to working with ida, especially if you don't want to be a reverse engineer. I tell anyone who wants to listen like there's still a lot of skills you'll learn from it understanding things like this whole runtime linking. You may never have to really deal with it. But hey, when you're analyzing binaries and you're doing static analysis and then you'll be able to recognize these patterns and I think it'll just make your. Some of your basic analysis and your triage analysis that much better. It's still worth the time and effort and just take out of it what you can. And if you never want to look at assembly again, don't worry or I guess use the LLMs. Uh, I'll be able to tell. Use them if you want.

Speaker C: I don't know.

Speaker A: I tried creating a defang tool and I went round and round on how to create it and I finally settled at I'm going to um, redirect the entry point to a little blob of shellcode that pops up with a message box and says are you sure you want to run this? Yes. Okay, cancel.

Speaker C: No.

Speaker A: And it works pretty good. I actually just added a new section in the PE file only added a new section, made it read, write, execute, patched the entry point to the shellcode, had the shellcode patched to the original entry point if they chose to click ok. Mhm. Then I dealt with the TLS callbacks in the rare case that something had TLS callbacks. Everything was going pretty good until I got to. Net binaries and for whatever reasons the Net even though it's still a PE file, I just um, was running into issues figuring out how to add the proper space for these things. Um, and it became a nightmare. So now I've got this project with hours and hours of work that's just sitting on my desktop and I'm afraid To I probably should get it out there because I can caveat and say, hey, this doesn't work with. NET files yet. I just have to fix it. But I just haven't got there yet because I like having. If you're teaching like a detections course and you want to use real binaries with the real strings and all the other stuff that comes with them, um, that would prevent it from accidentally being executed, you could say, I have a reasonable amount of confidence that this thing is in fact neutered. It's not going to execute unless somebody clicks on okay or cancel. And uh, I'd feel better about delivering that. And then that way they could handle the real binary. There'd still be a level of neutering that didn't substantially change the underlying file.

Speaker B: Yeah, I dig it.

Speaker A: Yeah. Yeah.

Speaker B: So we usually end the podcast with one to have you give one piece of advice that you would give to any blue teamer. So think of anything that you want either Brand new SOC analyst to grizzled re vet. What would you tell them?

Speaker A: I don't know.

Speaker B: Yeah, no, it's rough.

Speaker A: Yeah, I don't know. What would be something actually helpful is what I'm going back and forth on. I think at the end of the day what I have found to be the most valuable, no matter where I found myself, is just the lower level of detail I can understand the better, better it's uh, equipped me to handle unknown situations. So if you're someone who doesn't like looking at ones and zeros and looking at assembly, I think ultimately the more like Windows internals, whether you're reversing or you're offensive in nature, like the lower you can go and finding the areas that you're interested in, I just, I think that's going to be the uh, the thing that really benefits you. Yara rules, another great example. You can write rules with strings, but a lot of times strings are hidden and at least in executable files and being able to use code patterns and, or even understand them, I think that's kind of an interesting challenge. You look at a Yara rule that's just a sequence of bytes. Can you figure out what those bytes represent? And if you can, do you have any idea what context and where that came from? And how good is this actual rule? And so being able to go low lets you answer all those questions.

Speaker B: I love it. I feel like Yara rules are a dying art, but they're around. I will say I've only had one company that's ever Had a tool that works with Yara and it was their email tool. Not so.

Speaker A: Oh really?

Speaker B: It is a very old email tool that uh, I was trying to get rid of while I was there.

Speaker A: What's the replacement?

Speaker B: Oh man, now you're gonna make me an ad. But the replacement for like Yara, I would say nowadays is like Sublime. If you've looked at Sublime Security. So they do email analysis. They're very detection engineer heavy and it's all in Pythonic. So very close to like Python. It's really, it's got a really bunch of nifty stuff. They have a free version that I actually have hooked up to my corp, my LLC's email and I play around with it quite a lot, but highly suggest checking it out.

Speaker A: Yeah, yeah. Well, uh, you know, I work for a company that, that owns Virus Total, so.

Speaker B: Yeah, I know.

Speaker A: Still very much.

Speaker B: Yeah, yeah.

Speaker A: Big, big part of the.

Speaker B: Nobody. Nobody. That doesn't count though. Like, only it's Virus Total.

Speaker A: No, I haven't heard that. I'll check it out. Definitely.

Speaker B: Cool.

Speaker A: Okay, awesome. I uh, could talk all day, so thanks for your time.

Speaker C: Yeah, thank you so much for joining us. This is amazing.

Speaker A: Worth it. Got you something that was worthwhile and very much so I can do. Please don't ever hesitate to reach out.

Speaker C: Cool. Awesome. Where can people find you? Just. We'll plug all of your stuff.

Speaker A: The Cyber yeti dot com. That's the place. Everything links from there.

Speaker C: Sweet. Thanks, Josh. Uh, for those who are still tuning in, if you liked it, like subscribe, give us all a star, share with your friends, all those things and we'll see you next time.

Speaker B: See ya.