 Everyone, this is my first DEF CON, but I'm not a youngling, so please don't be gentle. I need to touch a frying pan at least twice to confirm it's hot, the second time to confirm that the first wasn't a trick or an illusion. I gotta be totally blunt about something right now. There is zero new information in this talk. None at all. Killer intro, right? Well, at one point in history, clocks were a very commonplace item. Bells were also a very commonplace item. Someone eventually put a bell on a clock, and the modern alarm clock emerged. Nothing new. Suddenly, as common folks are able to wake up on time for our lives. The jury is still at whether that was a net benefit to humanity or not, but you can't argue that it's an extremely useful artifact to come from combining two household items. But today, I want to talk to you about some creative munging. There are incredibly gnarly instances of innovation by combination throughout history. At one point, someone wondered why we push around pineapples and bags of flour in grocery store and wheeled buggies like royalty, but we carry our equally heavy or heavier suitcases while traveling. And now it's hard to find a suitcase without wheels. Recently, really smart people have basically combined Wi-Fi and cellular tech to give us 5G. Looking back a lot further in the 1400s, a German hacker named Johannes Gutenberg probably unrelated to our founder Leonard Kutman, but we'll just assume the hacking community in Germany is pretty tight, so they're probably descendants or time travel buddies or something. Anyway, 600 years ago, a German hacker combined a coin punch device with the concept of setting type from a wine press machine, and this led to the mechanical printing press. This means humanity went from printing 40 pages a day by hand, copying exactly only a few pages per day to now we're capable of 3600 pages per day, the dawn of the information age. Back then, when you can print a book at speed, at scale, obviously, you print the Bible. The rest of that story is actually pretty fascinating as well. So like any good researcher, he disclosed his year 1450 zero day mechanical printing press thought exploit Bible churning machine and his investors took over the company and nosedived it to the ground. They even brought him back on board like halfway through that nosedive just to make sure he was also financially wrecked. So yeah, cool tech, VCs flocked in, everyone gets high on the smell of money. They come down harshly from that high and now there's no cool tech anymore. Clearly, this move wasn't invented in the valley. Not be ending for Gutenberg, but a cool story either way. So we got the printing press. Innovation through combination has been a really cool part of our technical history. I just said our and I haven't even mentioned who I am. Hi, my name is Abe. I am in charge of making sure that everyone has a good time with Greylog after they've joined the Greylog family. In other words, I run the training department. I wasn't always just a meat based instructional video, though I've actually been in cybersecurity for quite a while now. I got my start in the 90s in the same way that most people did with an internet connection, a gross underestimation of authority and a misspent youth. I'm always so glad my mom kept newspaper clippings. You know, Pixar didn't happen, right? So as I grew up, those exact character traits led to a segment of organized crime, a very particular branch of organized crime where I did some cyber security things for Big Brother. Really though, it's Canadian Big Brother, so it's really charming with above average quality of music. After that, I worked in IT and operations for another government entity, local government. Then in true IT fashion, as we always plan for our senior engineers and analysts getting hit by a bus, but in reality, they get hit by a better offer. So it was my turn to get hit and here I am. I'll let the young and hungry keep their pagers or slack DMs or whatever you carry now for late night operations calls. I'll build terrible PowerPoints like a proper manager. Talk me down on the socials if you have any questions about my history that you want me to ignore or to send me memes, memes, days, memes for days, memes for days. Blood the internet. Okay, I'm off track again. Hi, I'm Abe from Grey Logs. I'm the trainer there. There. Enough introductions. I've titled this talk log jamming. Log jamming means a couple of different things. First, it's a bunch of logs jammed together, literally. Since I work for a software company that earns revenue when you send in more logs, you have to go ahead and literally send them all in until it's jammed and we'll figure it out and make it bigger. Second, it means an impasse or a deadlock. In other words, you've encountered a situation that simply can't be overcome. In the famous words of Walt Disney, it's kind of fun to do the impossible. Well, we're not going to do the impossible today, but so we'll walk it back to another quote. This one's from Steve Jobs. Creativity is just connecting things. In our case, we're going to use log jamming to overcome our log jamming. This talk is breaking down some of the highlight reel over my last few years, dealing with security analytics platforms, centralized event management. I'm going to reiterate the challenge of this talk to show you stuff without really showing you anything new or groundbreaking at all, just different uses of old. I'll start with my first tale. It's one of my favorite tales, actually. Sadly, it's a project and the project kind of fell apart for sort of unrelated lawyering reasons and the motivated entities on both sides parted ways, but the good bits are what I'll focus on. So the backdrop. A former employer had a program called Teaching Cities, part of a much larger provincial or federal initiative and current encouraging local government bodies to enable their local government things to be used helping academics in the future generations. In other words, let the school kids get their hands dirty. Great initiative. I think it's super mega cool. Engineering students go out and do their engineers, sorcery on wastewater management or civil construction projects, etc. There's a technical university with a really solid future leaning reputation in the same city as my former employer. This particular school has quite a blossoming security program, actually set of programs at a variety of levels, associates, bachelors, masters, whatever. You can go get your degree and hack the planetology and do your thesis on cracking Gibson's or, you know, nerdery a-a-as on a loop. Whatever happens behind the curtains. I haven't gone. So so we have Teaching Cities encouraging the use of city resources and a hacker school across town. This sounds awesome. The institution approached us with the idea of putting some dirty, rusty old box on the outer edge of our network and seeing if they can come at it. Cool concept, but a single made to Pone server just sounds boring, right? CTF with a single flag. Come on. It was very little work, but at a very little gain. I'm a much bigger fan of like the train like a fight model. So my response was, hey, university institution people, why don't you just poke around our perimeter network? Use the public IP space and in exchange for this program and this relationship staying alive, give me a report on anything you find. Basically, it's like using interns in a bug bounty program. Anyone who smashes through a perimeter during an introductory university level hacker course is the person that we should be handing a job offer to. My first pitch was met with resistance, actually a hilarious amount of resistance, like bug bounties are an established practice of using interns as an established practice. I mean, they even get paid an exposure or whatever we call nothing tokens these days. Bug bounties exist, internships exist, but nope, we absolutely cannot use interns in our bug bounty program. So let me get this straight. We let inexperienced, untrained university students build bridges over water and expand gas lines and run full ecological maintenance cycles on forests and park lands. But letting them poke at a segmented web servers too risky, huh? What? Because cyber and no one knows what we do here. Fair enough. We've all been there. So myself, a couple of the profs, some of the teaching cities folks anyway, we all listen to the concerns, address them like adults and got underway. The first run of the program went exactly like this, like the point is the proof of concept. My phone rings at my desk one random afternoon and I'll put on my my prof app prof. OK, group one is going to run a basic vulnerability scan. Cool. All right, I'll watch the logs. Oh, I see. I see. Oh, oh, no, never mind. That's just some some, you know, internet wide scanner in France. Oh, I see it now. I see. No, no, that's that shady printer and accounting that port scans the land every time it prints for some reason. Hang on. Oh, there. Oh, no, that's that's not it either. And then I promptly forgot what I was working on and walked away into a meeting. Sorry, group one. Later on that day, phone rings. Oh, I guess we lost you. Group two is going to go now. Oh, excellent. Yeah, let's do this. I'm watching the logs. Oh, group two isn't quite ready yet. OK, waiting. They're having issues running their eighth and ninth Windows server VM on this refurbished Chromebook. OK. And now this time I walked away on purpose. Phone rings again later. We'll get it sorted for group three. Yeah, sorry, dude. It's coffee time. I'm out. No work on break time. You get the idea from, like, my crystal clear acting, like crystal clear acting. So like Hollywood, if you're watching, I'll stand in for the rock or Jason Momoa, whatever you need. But at the summary of this initial experiment, there were technical limitations on mostly on the college student side, but equipment difficulties and networking difficulties from time to time, the occasional disinterested student group and really what like the ultimate way on the project was that it would turn into a huge time commitment on my end for what was largely a pet project. So I had actual things to manage and actual security stuff to do. So this was not going to keep the higher ups at the office happy for very long. This needed to improve. I actually kind of, you know, sending back and doing like a problem analysis. I saw two big problems with this. One, I was the broker for the actual information they needed. This meant I was basically stuck sitting there being a live analyst. As I was the one with the access to the log data and can interpret it. So I could potentially expose the entire stream of log data to the classroom or whatever, but that would probably have some pretty far reaching and obvious information as concerns. Second, I need to actually isolate the campus data, you know, the from the public scanner from France or whatever I needed. I need to keep those people out and separate in one way or another. So I wasn't doing an analysis on the entire public internet while trying to give them feedback. And when I say all of this, most of the people watching this video from Def Con, there's just a ton of noise on an internet facing system, even at just the firewall level. And 20% of that noise is probably from people attending these talks right now. More than half of that being actual exploitation, definitely coming from people at this event. Anyway, the you all cause that noise. Hackers ruin my day, at least when I was a Fed or a rent a cop version of a Fed. Tilly hackers. So I needed to conjure up the relevant data and separate it from the fluff. And I needed to communicate that effectively and preferably asynchronously to my own life and commitments. In other words, I needed to automate that shiz. The problem one was kind of half solved, but something as easy as a Slack channel. So that's halfway through problem one. Easy enough. Now I can ignore boring actual work meetings and, you know, chat away to cool baby hacker college kids. So halfway through problem one of this Slack channel. Cool. Problem two is a bit trickier. The solution was largely made possible actually by cleverly abusing scheduled policies on a firewall or to gates before you ask. Most UTMs have the ability to schedule policy rules. If they don't, Cron and SSH can step in. But most do, especially large sized, you know, perimeter gear. So I used schedule policies to just crank up the logging and schedule a window for the students. Like dial the logging up to 11. I can narrow it into, you know, either GeoBand or whatever. Dial that all up to 11. This meant I didn't actually have to use any specific WAN IPs either. They could simply work from wherever. Just do it between 7 and 9 p.m. or whatever. So another added benefit was having specific policy numbers now. So with that new scheduled policy, I now have, you know, rule number 510, rule number 512 or rule 500 to 600, which makes searching through the noise data a lot quicker and a lot easier. Basically, the firewall itself is tattooing the relevant data for me just with that policy number. That's fantastic. So now I've got policy numbers that can actually trigger the logic and eventually auto communication. So simple alerts based on hitting those new schedule policies really cleaned it out, but also kind of help them see if there was Internet mess mixed in there. As soon as that was communicated to the Slack channel as well, they could see what they're up against. You were trying something that people are trying every five minutes. Think a little wider than that, right? So feeding even the generic noise back into the channel during their scheduled window helped them really see what noise looked like. So if they wanted to either look like noise or be completely different than the stuff that's already got a lot of rules against it, they had that feedback now. So this shiny, new scheduled traffic all flowed through a totally non-denominational, vendor agnostic, monochromatic blank box product, of course. Actually, wait, no, we're a sponsor right now. We're sponsored. OK, screw that. This all went through Greylog. It all went through Greylog. Super easy parsing engine, simple and effective event engine and great output logic like Slack notifications. So after the first run with live IPS, AV and firewall event data, all being dumped into the Slack channel, just the UTM rules, adding new logic, fine tuning granularity, it blew up so fast it was crazy. Within a few more weekly sessions, we had the spam filter logs for phishing simulation, including a link clicking sandbox that the students actually built, which is super cool. If I remember right, it was some sort of I map voodoo running into cuckoo, all spun into containers, but I could easily be screened out. Anyway, they had an auto link clicking thing that we ran, and if they sent in links, it would click on it and we could see how the rest of it played out, which is cool. We actually got a lot of really good intelligence out of that. We eventually also had a one-to-one replica of a production platform that allowed unauthenticated file upload, so all feeding their locks. So, you know, if they're uploading a whole bunch of shady.js files or whatever about PHP, and we could see that, putting all these various layers into Greylog, being parlayed back to the students themselves as they're trying the exploits. We could even, you know, we'd simulate it at times. Oh, you've got the band for an hour. You've got the band for an hour, right, for 30 days. Ooh, that's a nasty one. You triggered the IPS on a critical. That's, stop halt. And never did we have any issues. So, parlaying it back to the students as they were trying it. I mean, the more I thought about it later, and as kind of time has gone by, the more we realized we're basically describing more or less the automated feedback loop from purple team exercises, except done in a way that I felt most comfortable myself. In other words, it was done completely unprofessionally and totally hacked together. But it was awesome. Lots of fun with the college kids. So that was my first adventure that I wanted to bring up. Nothing earth-shattering, technical wise, but rather than throwing hands in the air and giving up at our log jam, see the loop back. We methodically attacked the root of our problems and blended the solution together, scheduled firewall policies made for straightforward alert logic into a chat program for feedback. This actually made for a really fun pock for baby hackers. No idea where this project is now, but hopefully someone found my shoddy documentation, blew the dust off and tried again. Baby hacker school. So I've never before and never seen since scheduled policies abused that way outside of maintenance windows or Internet restricted machines or blocking Internet hours because someone works the late night shift and likes to abuse the Internet. Anyway, so that was old tech used in a new way. Speaking of Internet abuse, however, story number two, once upon a time in a land far, far away, I worked for an organization that was building a large equipment operation depot. The building was all done, but nobody was really working in it yet. We went in and suited up a bunch of, at the time, state-of-the-art Wi-Fi. It was going to be so exciting. These particular APs had all kinds of cool tech. It was the first walk about, roaming AP to AP, Wi-Fi where you can go one to the next without dropping connection that I had been part of deploying. It was the first one that I'd been on that had heat maps, density maps from estimated foot traffic, et cetera. It was cool. And speaking of bells and whistles, these APs had some pretty groovy security tech baked into them. Now, caveat, I believe this particular protection has been patched out for a couple of reasons, but I won't name and blame the vendor. If you're Googling, you'll find it from the story. Anyway, there was this really cool security protection against evil twin attacks. It got our attention, how do you protect against that? We didn't know what it was or how it worked. Or anything, it was just two checkboxes, evil twin attack detection and evil twin attack protection or prevention. I think it even said beta or, you know, this feature is incomplete and dangerous or something. Anyway, we rolled it out. Since this building was kind of far, like geographically far from us, we were doing everything remotely, but it couldn't shake like, what does this actually do out of my head? So we remotely activated some laptop in a dock and played with its wifi to broadcast a network with the same name, you know, basically simulated and actually technically doing an evil twin attack. So that's what we're working on. It should have been like an easy detection, right? Like, no, but nothing, like we get nothing. Nothing came out of that. There was no cool evil twin protection, no logs even showing the detection, no like tiny cannons popping out of the access point or flamethrowers, no Bill Murray riding a dinosaur that shot lasers out of his eyes, nothing. Like, total bomber. Dad, it was just, oh, we were so disheartened. Anyway, most people would let that go. But like, I had to know. I'm like, the checkbox is here. Somebody deved this. I want to see what they deved and what it does. So I jumped in a car. We drove down there. Let's see this thing in action. There's a knob that seems irrelevant and all for thoroughly testing it on company time way over scope of the project. So we walked around broadcasting our wifi range. Nothing, not a thing. No idea why, maybe it was propagation time, who knows? Whatever we did, nothing worked. Oh well, evil twin protection wasn't actually in the deployment scope as I kept getting reminded. So I had to give up and walk away. We did, packed up, went home. Exhaustingly. We were eventually able to trigger the detection pretty much by using a few other commercial APs and the evil twin protection was simply cranking the antenna power out of any AP that detects the malicious SSID to 11 or whatever max power is for a configurable amount of time. So in other words, you have your wifi named super ultimate hacker and you set up an SSID called super ultimate hacker. The APs that detect that just crank their juice to 11 for 3,600 seconds or whatever it is. So that's all it was. Is it an hour or two as the default? It was boring and nothing space age at all. I really wanted tiny cannons out of the access point. Anyway, as with any test that leads to complete disappointment, we literally packed up our gear left and enabled and didn't turn it off. Who cares? It's boring anyway. What does do something? So a few days later, our test alarms light up like Christmas tree about an evil twin attack. Yes. Awesome. It's not even one of our test systems. This is a legit real hacker in our parking lot. Yeah. The entire security team is feeling like a badass level somewhere between hackers and sons of anarchy right now. Someone is going down and we are the super humans that are causing this. I don't think anyone really stepped back and thought too deeply about how much energy we're putting into an alarm that we couldn't even manually trigger on the test day. But that's not really important right now. We have a live hacker on the hook. We dove into those logs headfirst with various faces and started looking around. We quickly learned a few key pieces of information. First, the MAC address was not a well-known vendor address. It was an actual known vendor. Just none of us recognized the name. It was in the thing. We're just, what is that? Second, the AP and the parking lot had the greatest signal strength by far with the next two being roughly equal. In other words, our MacGyver super ultra genius napkin math triangulation told us that the hackers should be out in the parking lot. So it's most likely at this point a nation state team in a series of black panel vans with a special forces strike force all around us in the bushes and along the neighboring fence line. It's a privacy fence. So this is entirely possible. It could just come 10th mountain over the hill in tanks or whatever. Probably North Korea, Russia and China all charging over the fence at the same time to attack our parking lot for some reason, at least our Wi-Fi. We detected an evil twin attack. What other scenarios could there possibly be? We eventually remembered in all of our excitement that we actually have security cameras. So we pulled them up and as it's loading we're all waiting, we're all waiting. Looking at the parking lot, you wouldn't believe what we saw. You ready? Nothing. Not a single vehicle. No black van, no special forces team, literally straight up 100% nothing completely bare bones empty parking lot an empty stretch of concrete. We actually saw the same protection pop on and off a few times over the stretch of an hour or two. That was it. Never a vehicle showed up. So a small team of security and IT operation nerds put their tails between their legs and went home that night with completely broken hearts. I'm sure there was at least one pair of superhero pajamas worn to bed just to feel better. Well, redemption was still possible. About three days later, the alert occurred again. This time, plot twist, parking lot wasn't empty. However, after driving around, doing some range checks, some strength testing, we confirmed this evil twin attack had to happen within the area of the parking lot, at least within a couple of feet of the area of the parking lot, but it was empty on the screen every time or verifiably not belonging to one of the vehicles in the parking lot. We were complex, totally cum perplexed. We did have one new piece of information though. The MAC address was the same vendor ID, but a different MAC, the same weird vendor. Well, we got that alarm a day or two later and then again and then again one more time. So now we're nowhere near as excited, but we've just kind of still telling all of our friends and family that we have an ultra-patient APT level MAC address spoofing campaign going on, but these international criminal supervillain spies were not going to outsmart us. One of our group had the genius idea of seeing if we've ever seen this MAC address or vendor before. We actually have. That vendor ID has popped up at one or two other sites occasionally. In these other instances though, the MAC address didn't change. Same device had a history of occasionally connecting to our public Wi-Fi. Now just to remind, this is a public Wi-Fi network that spans across one of the larger cities in Canada. So it's not a tiny network. We had no idea what these devices did and still no idea what it was. The nature of our logging infrastructure meant we didn't have records of what traffic these devices were generating when they connected. None of them were recent enough for that logging. The IPs were all long recycled to other devices. Another interesting note, these devices, the ones that we had previously seen, hadn't connected in months. This is springtime, so that actually becomes an important fact of the story. We enabled some pretty detailed layer two logging and filtered it down for that particular vendor ID across our whole infrastructure. Now remember, not everyone's from network operations, but remember if you're running a homogenous network as in everything from the same brand and product line, which really nobody is, then it's actually a pretty big challenge. Unless you're doing that, then it's actually a pretty big challenge to monitor traffic from layer two filter. In other words, a specific series of MAC addresses onto what actual traffic they're doing, what is the actual traffic they're generating, web traffic or API, whatever else it is. We can do packet capture, which is ungodly expensive resource-wise, or we can use a NetFlow variant, which is spotty at best, that's sampling. We wanted to know the traffic being caused by a specific brand of network card. In the end, we finally had it. We tagged the DHCP logs and added some additional information. So we pulled a lot of stuff off our Wi-Fi controller, added a little bit to kind of generate our own sessions, and then tagging those sessions from the first level of NAT device. So as soon as they go from one brand of Wi-Fi controller across a router, you've now lost that MAC address information, which is what makes this challenging. You've now lost that. So we had to kind of give them a fake session that carried over to the next set of logs. Hey, if you've seen this session, add it again. Great. And so we were able to carry that on. So we now have traffic logs. The traffic from these highly advanced adversaries, when we finally got it, when we finally got it, we couldn't believe it. The traffic was to, I don't remember the exact URL, but something along the lines of api.webersmartgrilling.com. Our enemy that was gonna roll over in tanks was a handful of smart barbecues. Our nation-state level threat actor was a tool used to not burn chicken. Given how much we had hyped up this whole thing in our heads, it was definitely a solid laugh cry moment, followed by days of uncontrollable giggling. Like seriously, we had this hyped up in the office. It was pretty good. We were all pretty convinced we were gonna completely uncover some huge, like the Illuminati at the least. Note, note completely overpriced hot dog cooking tech had us baffled for weeks. The rest of the pieces started instantly making sense. Other folks who lived close enough to our facilities to leech-free wifi simply hadn't barbecued yet this season. And now that we had all the, we did have one piece of the mystery left to solve though. This all started with an evil twin detection on our access points. I mean, someone publishing our wifi name on their device. I mean, now we're kind of, we've narrowed it down to someone publishing our wifi name on a freaking barbecue. But we actually went as far as using our security camera, zoomed all the way in to find the right brand of barbecue in the nearby backyard, because you'd see it from the top of our building over the fence. So we politely knocked on the door and explained our situation. The particular barbecue user found the whole story side-splitting hilarious. We asked them, you know, how are they configuring their barbecue? After assuring them we're not pulling the plug in your free internet, continue to leech-free wifi. We barely scratch our bandwidth capabilities. We just want to know what happened. So turns out some of the variants of the smart barbecue act an awful lot like a Chromecast. They can both connect to wifi and use cloud services to push your grill notifications back and forth. Or they can be configured kind of non-cloudy as a local wifi AP. So this particular user decided to name their local barbecue wifi with the same network name as our public wifi, so they didn't have to switch their phone settings back and forth. They could just sit near the barbecue and it should work. That was the thought in their head. Whenever they tried setting that up, they then complained that this actually screwed up the wifi all over their house. All of their devices went completely haywire so they would take the motherboard of their barbecue back to the hardware store and get a replacement for another. Changing Mac addresses. So we've now narrowed down why we had changing Mac addresses and the evil twin attack. Tried it several more times until eventually gave up and just gave it a proper local name and away it went, so we never saw them again. And then some folks from the city started knocking on their door asking about their smart barbecue. So that was the fun one. They're potentially a clever way of just not having to switch your phone's wifi. It didn't quite work, but the moral of the story is leaching public wifi for your barbecue might end up with advanced persistent civil servants knocking on your door asking questions. So to summarize, we combined DHCP logs to summarize the tech at least. We combined DHCP logs to NAT device logs to web traffic and DNS logs to make, it took some pretty serious finesse to get those all talking to each other, but it was doable. And eventually we're able to filter on vendor Mac IDs and any other aspect of that change is totally possible. How be it, if you wanted to drastically cut down on some time and effort in doing it in gray log, you'll want the MongoDB lookup table. So if you're small scale, check out the small business or upgrade if you're doing this at the office. So anyway, that was one. That was a big case for how before I got to gray log, we ended up on enterprise. On to my last tail. Now this one isn't even so much as a tail as an entire category of function and against. This concept actually came from a portion of the gray log analysts class where I asked guests to just tell me stories like the ones I've told you now. One of the better ones by far was a fellow who really enjoyed playing tricks on his relatively non-techie family. So this last story has a pretty simple premise. When you have a security analytics platform that can also execute code. In other words, one of the event notifications for gray log is running a script. You have a security analytics platform that can also execute code, run that script. You now have something that can monitor for events then take actions. The scripting part allows you to take any action. What this means is you actually have a giant if this then that engine. When something happens, do something else. The world is your oyster and this is how we abuse oysters. This particularly shifty student at his usual home network monitoring going along. It was actually just Syslog from a really boring commercial Wi-Fi router. He started parsing the Syslog events at one point and tagging the DHCP records with the owner of the devices. He started building up a bit of an impromptu active asset management system. So when the kids will call them Phoenix and Phalanx or whatever their names were came home, he added a field to the log saying Phoenix Apple Watch or Phalanx's Xbox. Most of the stuff is kind of in there unless they've renamed it something silly. At one point or another, he was trying to build a bit of a digital notification system, a vendor agnostic version of the Zoom attendee announcement. Kyle has joined the meeting, but instead being Phalanx has entered the building. That was the end goal. While testing it out across his Sonos system or Google speaker group, whatever it was, I believe it was Sonos, he used some sample MP3 files before working on the text-to-speech component. So he used these sample MP3s to just kind of grab and use this as part of it instead. It never made it to the text-to-speech phase. He happened to choose some sample MP3s that kind of randomly matched the personalities of his family members. He, by total accident using his log management tool, a Python script and some household tech, gave his entire family wrestling style anthems when they walked in the door and their devices connected to the Wi-Fi. How perfect is that? No, I don't want to simply regurgitate someone else's story. So I obviously had to set up some POC for this myself. Great Scott, this was fun. Check out my test sample video. My kids are really weird. Now, unfortunately due to calendar-giving snafus, I had to ship this talk before I could see this all the way through to my end goal of every time the word Minecraft was Googled in my house, play this sample video on every TV. I did, however, get the latter part going without any issue and so, I'm even able to run persistently through the house. So here it is, pleasantly interrupting an unsuspecting innocent child who was politely asked to lower the volume on their YouTube video several times. Now, they get some geek dad rat. Movie file, set up properly. Hopefully that worked, it's a one-liner. We're serving it up, just Python HTTP server and behind my lovely face is the fuller. Here we go, are you set it up? Let's see what we got when we run it. Quick hijack of the Chromecast. An angry kid. If that isn't modern-day parenting at its finest, I don't know what is. I wish I had more time and then we could talk about stories like this all day. One more time, I'm Abe. Find me posting nonsense on Twitter, LinkedIn, GitHub. You can follow me at Big Abe20, follow at Greylog for awesome stuff. Big thanks to everyone at Blue Team Village. More shout-outs to everyone at DefCon29. You've put on a really awesome show this year, despite the learning opportunities. See, always a manager. And thanks to my team at Greylog for always moving the finish line and making a great tool. Last and most important, thanks for checking out my talk and staying right to the end. I will see you all around. Enjoy DefCon.