 Welcome to my talk. This is UP and proxy pot fake the funk become a black hat proxy men in the middle of their TLS and scrape the wire For begin I'm Chad seaman, but around here at DEF CON. You can just call me dirt. I Am part of the ACMI cert team I'm actually a team lead and senior engineer on that team for those of you unfamiliar with the cert team Which is probably all of you You may have heard of some of our research before We focus on DDoS and emerging threats research But that typically leads us down the path of malware and botnets and proxies and other good stuff So before we begin you're gonna see me talk about IOT a lot of you are going to think IOT means Internet of Things That's not true for me. It's the Internet of trash whenever you see me say IOT that's what I mean So what's this talk about? Well ssdp and upnp have been widely vulnerable on IOT devices for nearly 20 years It's not only possible But also very easy to turn these devices into proxy servers when attackers find vulnerable IOT devices susceptible to this kind of attack They turn these devices into short-lived proxy server and delete their tracks when they're done If they don't delete their tracks the tracks will delete themselves We're going to cover ssdp and upnp previous up and proxy research camp and campaigns Conducted by me And finally up and proxy pot how it works and findings from a year of geographically distributed deployments So first things first ssdp and upnp ssdp Stands for simple service discovery protocol It's a technology that's built for the land Uses broadcast addressing with http over udp. It essentially allows machines on a land to announce themselves and or hear announcements from their neighbors Or network peers and then expose Them to upnp which will in turn expose services such as printing and media sharing and network configuration all that kind of stuff Upnp is universal plug-and-play. It's also built for the land. It's good Good old http and soap Soap as in xml It lets machines on a land inquire about the services configuration options offered by that device It also allows them to access those services and or potentially modify those configurations So a good example of this is an xbox, right? An xbox or a pc game may need you to forward certain ports or certain traffic around the firewall Rather than deal with the state of managing that in the net So that's what upnp basically enables it allows your xbox to go forward and say hey Poke a hole in the firewall send everything on udp, you know, one two three four over to me so What is wrong with these technologies? Well for ssdp iot devices are notoriously bad at deploying this correctly. That's the same as true for upnp It's built for the land But they stick it on the wan just because I don't know just because it was a reflected d-doss vector up-and-coming most popular mvp King of the hill whatever you want to call it in 2014 and 2015 It's still fairly popular for that, but it's not as popular Mostly due to other vectors becoming more popular not because it's gotten that much less abused Um, we're still finding this bullshit everywhere older products are still on the internet Amazingly newer products and new is there in quotes, but uh some newer products And by newer I mean within the past few years Still have these problems so 20 years later at a minimum 14 years And here we are Still having the same more problems So upnp universal plug-and-play Once again built for the land, but they seem to just love to stick this stuff on the wan too It treats the land as a safe space, which is fine But the wan is not a safe space. So when you're listening on the wan and thinking it's a land It's a little bit of a problem Um, it just does whatever its trusted network peers tell it to do does not require off There's not really a whole lot protecting it Information disclosure it will tell you everything model numbers makes serial numbers Uh on top of that it will tell you how to talk to it what services it exposes what configurations what data You can push in and what data you can expect to get out It facilitates configuration changes on some devices it makes it very easy to do those changes In some cases there are known RCE injections in the upnp daemons in the soap handling so your Basically soap can can get remote command execution on the underlying device So let's take a quick look at the history here and why I talk about 20 years the first instance that I could find of somebody Exposing something here is a 2003 join stickler He came public with a netgear upnp information disclosure A couple years later I'm going to slaughter this guy's name our meanj Himmel I think in 2006 gave a talk at the same conference Uh, and he launched a website Called upnp hacks.org. There's a ton of great info here His talk really kind of blew the lid off of all the problems that upnp actually had and all of the potential vectors It could expose people to And then in 2011 daniel garcia gave a talk at defcon 19 called upnp mapping. It was a great talk It kind of touched on this proxy and capability and some of the problems with upnp I was in the crowd It freaked me out enough that I think my tp link router at the time was actually impacted by this And they went ahead and I went ahead and Remoted into my home network and disabled upnp from from the talk while I was in the talk from my phone so A brief history of upnp proxy. So upnp proxy in 2014 like I said ssdp is the new up and coming d-doss vector Starting to see it abused pretty widely We Akamai cert at that time we were known as the plx cert Are asked to write about it, you know start digging into it put down advisory and all that good stuff So in 2015 this this was happening at the end of 2014 At in early 2015 the ssdp research leads me to discover dupnp And it kind of Turns on that that 2011 talk in my head. I'm like, oh man. I remember this being like a shit show so in 2016 I decided that since it's been about a decade after The sane conference talk and the upnp hacks It might be fun to revisit this and see how bad This this landscape is Are we talking hundreds of thousands? Are we talking millions? and just talk about And kind of try and bring The fact that this is 10 years later these things are still a problem and these threats still exist in the real world And everybody just kind of seemed to have forgotten about it So I start writing that paper The reason it's relevant is because I had to write a tool chain To test some of these theories and concepts This is a tool chain here that was for testing the NAT injection capabilities on exposed upnp devices so In the top there you see the ssdp banner that we get back We take the 192 16801 We change that to the public facing ip address that we found upnp responding on In our soap payload we set that port 5555 Is going to port in point into 192 16801 which we know is the router at this point on port 80 We then issue that soap request via curl And what we see here is before the injection and after the injection in the scan results there TCP 80s filtered you couldn't get to it But once I opened TCP 55555 And then I hit it in a browser. I am greeted with the admin login page So that's a little bit a little bit of a problem being able to get around the firewall that easy As i'm doing this research In september of 2016 We get hit with a 620 gigabit per second sustained DDoS attack from a botnet At that point the botnet was unknown It ultimately got named Mariah So as I'm digging into that I'm inspecting attack sources. I'm seeing lots of iot. There's a decent overlap with the existing identified upnp dataset That I had from my decade after disclosure research I decided that the upnp info leaks could maybe help And I start scraping those and poking these devices in general trying to figure out what the heck they are So it turns out correlation is not causation The fact that these devices were present in the Mariah botnet has nothing to do with Mariah It's just that shitty devices are shitty And if it's compromisable one way it's probably compromisable about two or three In the internet of trash space that is So Having already written the script to dump the NAT tables as part of the NAT injection testing I started doing that just to see you know, maybe there's something weird going on in there that we could figure out It like I said, it was not related at all But what I did notice when I did that was there were some really weird entries in some of these devices out in the wild The entries pointing to DNS servers. They pointed to akamai CDN servers. They had been pointing at HTTP and HTTPS web servers Which is really interesting, but I have other shit to do Got a really big botnet. I got to figure out what the hell is going on So I kind of just stick that in the mental back burner and move on So on the timeline here, we're down here at the Mariah botnet and huge DDoS So while I'm investigating that I accidentally uncover the up and proxy stuff, but I'm too busy dealing with this botnet 2017 things start to calm down Mariah At least I have tooling to to be able to better track it and handle it So I start looking back at some of my other research And I decide I'm going to look at what some of those really weird nat entries were on some of those devices And I began scanning the entire internet And dumping all of the nat tables of all of these exposed up and p damons This is when we uncover the up and proxy campaigns So up and proxy uncovered by the numbers There were 4.8 million ssdp responders In that data set 765,000 had exposed up and p. It's roughly 16 So of those 65,000 were actively injected with up and p entries That's 9% of the total vulnerable population and 1.3 of the total responders Of those 17,599 unique endpoints were identified as being injected in these devices Typically if a device had one injection it had multiples The most injected destination had 18.8 million instances across 23,236 devices The second most injected destination had 11 million instances across 59,943 devices I point this out because it shows two kind of campaigns running simultaneously here The most injected destination obviously had a lot more Instances of injections across a much smaller pool of devices And then the second most injected destination had A lot less injections but a much larger swath of devices that they were injected on All in all there were 15.9 million injections to dns servers 9.5 million injections to web servers And 155,000 injections to hgtps servers While i'm doing this research i'm talking to some fellow researchers and friends And one of the guys goes hey i think my friend's working on something very similar Would you be interested in talking to them and absolutely i was I'm very sorry to the researcher i talked to i don't remember your name And i can't find the email and samantech did not give you a shout out on their blog So thank you for your hard work and i'm sorry What they ultimately found was that there was an apt group And they were running this inception framework Where the attackers were basically using these up and proxy instances and they were chaining them together so they would Log into their vps They would inject a proxy route that pointed to another up and proxy Vulnerable device they would then use that injection to inject another route then use that injection to inject another route that ultimately pointed out to their target destination which was a cloud storage provider For uploading their malware and then they would use that to upload their malware to the cloud platform and this is partly to get around detection right A lot of a lot of times you'll have these lists of known proxies known endpoints tour etc and when you've got a pool of You know tens of thousands of home devices that aren't on any of those lists You're much less likely to set off some alarm bells when you log in and upload a nasty file so Really interesting research I gave him my tools. He was able to confirm it was what we thought it was And then I was able to confirm in my data that I could see some of the similar clustering So what you're seeing here in the graph on the right Is two different bubble graphs The size of the circle is respective to the number of outbound routes found on that device And then every blue line Is pointing in the direction of a relationship. There's an arrow So where you see the thick blue on one side that is the tips of the arrows running into one another And there's there's clearly two different strategies the top cluster You have a larger pool With a handful of routes that go out And they all point into a smaller pool of devices that may only route to one or two or three things And in the bottom cluster you see a centralized high route out collection and then They all point out to different endpoints So it's it's just a different structure a different strategy of building that chaining But the chaining exists and I thought that's pretty cool So we find all this stuff But it's not super widespread. I'm just kidding. It's everywhere So there's 73 brands and over 400 models that we could identify and it's important there that I say we could identify because we were only able to successfully fingerprint With confidence about 24 at the space and information leaks and those information leaks weren't just What came from the upnp dam and sure it helped a ton because it's a super chatty Exposes quite a bit of information about the device like I said But we would also go so far as to attempt to see what other ports were there SSH banners anything like that that we could potentially fingerprint on we tried And still we can only get about 24 percent so that is Quite a quite a considerable amount 73 brands and 400 models is a nice chunk But you got to remember that there's 76 percent that we couldn't even identify. So who knows what they are this public this this publication goes live and You know the crowd goes mild. Nobody really cared. It didn't really get a lot of attention I was pretty disappointed. I thought it was a very cool finding but And I'm downplaying that a little bit. So a couple people cared The people that needed to care care. So I'll take that as a win. The research did get some industry attention Um through some some trust groups and work groups and stuff Uh did get elevated and passed along and it was ultimately used to help some isps support the case internally for Uh cleanup and and you know sanitation efforts So progress is made behind the scenes Some networks start filtering ssdp That's all good. Um, you'll you'll see that the result of that in the next couple slides Ultimately, I get an email from a journalist She's doing some work And she was recording this new show Her name is justine underhill and she wanted to talk to me about up and proxy because the episode she was recording was on IOT and security and everything else So while we're recording this video I decided that you know, she's asking questions about how hard is this how long does it take how much does it cost? And I'm like, well, I'll just I'll just show you So I pull out the laptop jump on uh the internet run z-map and I hit the first 1000 things that respond to my ssdp probe And then I start dumping their nat tables And while I'm sitting there showing her this I'm like, man, I think we just found something new Like this this wasn't in the previous scans And this is how I accidentally discovered the eternal silent stuff which it was cool because We we didn't really have a solid case I had proposed that Attackers could use this to route around the firewall, but we didn't really have a solid proof From our existing scans that that was occurring yet So these are what the injections look like after they go through our logging process and are converted into jason um, you can see that they are targeting Inside the land 192 168.10 space probably from the information leak from the ssdp banner And then so like they're on 166 you can see that they tried to open a port forward to 139 and port 445 so They're injecting routes into the land space And they are targeting samba or smb We named it eternal silence because samba and smb are Clearly being targeted by eternal blue pretty heavily at that point and the Spanish there there's in the new port mapping description There's some spanish and i am terrible at spanish so My gringo spanish is galete silenciosa, which go ahead and laugh at me But it roughly translates to silent cookie So up and p eternal silence is discovered and published Ultimately 3.5 million ssdp responders. So some of that cleanup effort worked We found almost a million less devices than we did in our previous research 227,000 instances of exposed up and p 45,000 had active eternal silence injections. There's no way to really know what they were up to But based on what they were targeting the eternal blue link is an educated guess And that educated guess is based on if i were evil That's what i would do, right? I've got this surefire smb exploit But everything that's running it on the internet has already been popped But you know what if i can find a way around some of these firewalls I can probably find some devices that are still listening on that that haven't been patched And now i've got a new place to drop my ransomware So that's cool. All this research is cool, but we still have problems The research up to this point it has been via passive identification This requires scanning the entire internet regularly to find stuff. It's time consuming We get lots of hate mail and threats for scanning stuff people don't like when you scan the internet guys relax Relax, you're allowed to scan the internet. It's not a crime. Okay It it's still time consuming It results in a ton of logs because we're dumping all of these nat tables So it ends up with gigs and gigs and gigs logs per scan On top of that, it's very time sensitive, right? We know that the attackers can delete their entries. We know that the entries time out So the odds that we're finding anything at all is pretty surprising Especially when you consider that that That reality So the real problem here is that we can tell Where they're doing stuff and where they're pointing stuff But we don't actually have visibility into what they're doing with it. So if we see them injecting, you know port 25 We assume it's spam, but we have no idea. They could be dropping odays against you know, sntp servers no clue so We need to fix that and that's where up and proxy pot kind of enters the fight if you will So what is up and proxy pot the 50 000 foot view? It listens for ssdp probes and it directs attackers into a fake up and p instance The up and p emulation is good enough to get to the injection phase. It's not a full implementation It could be improved But it's good enough From there we offer on the fly proxy capabilities with man in the middle content inspection and logging Tls stripping is also supported uh, all of this is easy to modify In the sense that if you want to pretend to be a different device all you have to do is change some xml files and some text files on disk It doesn't require code changes to change your device profile per se so It offers session based pcap capabilities So you can come back later and inspect the traffic that went over the sockets And it's written in go lang and bash So ssdp emulation The ssdp response that is currently in the project Was lifted directly from the most abused abused device that we discovered during the up and proxy research It's stored in a flat file and disk you can change it without modifying any code The one gotcha is if you update the ssdp banner and it changes the port on which the up and p Damon is listening on this is what the attackers pivot on So you will need to change the listening port in code that the up and p damon listens on I didn't have a configuration file set up when I wrote this in my initial thing. It's it's an improvement that could be made Uh, up and p emulation. So the up and p responses Are lifted also from those same most abused devices All the html and xml stored in flat files updating them requires no code changes Up and p emulation serves basic files handles and that interactions The attacker supplied soap is parsed and handled via regex It will respond with proper error payloads if criteria are not met or xml is malformed responses must contain attacker supplied data so that response use So that these responses use standard print f formatting So if you need to change your thing and you know, the attacker supplied port needs to be in this Chunk of xml you can just put the percent d and it'll be there So on the fly proxying Um This is kind of unique because the attacker gets to control their proxy configuration themselves So we had to support that so attackers submit their proxy config via soap just like they're talking to up and p We parse them and then create a session of sorts And then we scrape and log plain text across the proxy proxied session in both directions If they're proxying to tcp 443, uh, it's a special use case and we assume That connection is a tls connection And we do some special man in the middle in there So stripping tls and this is a hard slide to read. It it's very upsetting So attackers actually do some verification When they're using the tls connections The initial deployment saw connections But they would bail before actually pushing data across that connection Attackers are fingerprinting certs. Initially, they were doing this via the subject line There is an automated cloning process Where we began by pulling the domain out of the client. Hello We then go forward to the injected endpoint And we get the cert with the respective sni that was provided in the client. Hello We copy the subject field From the remote cert And we mirror it into a self signed clone cert And this all happens in real time when they first establish their connection This allows us to It was allowing us to bypass their fingerprinting and actually get plain text out of the tls flows Literally yesterday as i'm recording this literally yesterday it stopped working and I don't know why I don't know if they've changed their fingerprinting I don't know what is really going on but I have A year and a half Well, I have months worth of logs at this point that have this functional and now that it's about to go open source it breaks So i'm sorry. I hope we can figure it out so The other feature is the automated pcapping the project uses go packet It allows us to create pcaps on the fly using berkeley packet filters that are scoped to the individual sessions The individual proxy sessions As attackers interact with the proxy to injection the pcaps are automatically collected If you find something interesting in the logs, you can find the associated pcap and see the entire session easily In whatever your your favorite, you know pcap packet muncher is wire shard tcp dump whatever If you run out of disk space on your deployed honeypot, this is probably why that is from a single Machine down there at the bottom you can see that we had 81,100 pcaps That we ultimately collected for different sessions And of those pcaps it resulted in almost five and a half gigs of disk consumed so This part hurts as well The initial deployment was for one year and it was four nodes deployed across a single vps provider There were geos from dallas to london to tokyo 300 gigs of pcaps and logs were ultimately collected hundreds of millions of captured proxy sessions and billions of log lines And um, you know, I Downloaded all that and I destroyed the cluster and then I accidentally lost the backup so I Figured this out Literally like a day after I submitted the cfp to def con Luckily, I had a couple months before everything Was accepted and approved So I was able to deploy a smaller four node cluster For the two months between cfp and What you're seeing now so Ultimately four nodes deployed us uk india japan 39 gigs of pcaps and logs collected 230,000 captured proxy sessions and 22 million lines of logs The good news is I did have some notes. So not everything was lost from the previous deployment And the trends that I saw in the new data Are spot on for the trends I saw in the old data. There's not a whole lot's changed just a lot less data to back up The claims, but I promise you it's pretty much identical so observations The first thing is that they don't blindly inject their Their proxies they actually come and do some testing. So injections They first come and they insert a test proxy instant a test proxy instance Once they confirm that it works then they inject a real proxy They utilize it and then they attempt to delete it I say attempt Well, we'll cover that so This is the process of an injection we see them show up with their imsearch banner We respond with our ssdp response here and you see that we point them to 192 16801 on port 2048 And then etsy linuxigd gate desk dot xml We see them come back within the same second And they then request that you can see ssdp in and upnp in there They request that And from there, they think that we are the device they're looking for Once they have confirmed that then they come back and they attempt to add their port mapping So in this case, they're adding An entry that will force us to listen to on port 222 80 It's a tcp socket And any traffic received on that is going to be redirected to port 80 on the host at 74.6231.21 You can see down there the new port mapping description Kind of mirrors the external port that they use that sync and then a number And then the new lease duration is 600 seconds. So this This will time out after 600 seconds Then they come back and they utilize that newly injected proxy. So here you can see they sync 2280 Everything up there between the curly braces is the Uh proxy configuration. We can see the source. We can see where ultimately they're going to point to so 93191 3976 On port 53 57388 is going to send traffic to 74 6231 21 on port 80 Ultimately, we intercept a get request to yahoo with no headers. So it's super easy to spot and yahoo because they move to HTTPS Ultimately issues a 301 permanently moved and this is all they really need for their fingerprint Once that's done, we see the attacker come back And they attempt to delete the port mapping, but they send us malformed xml What's interesting here is that the malformed xml apparently has I don't know if they forgot a null at the end of the envelope, but it continues as a buffer Overread and what we ultimately see here is xml that is not related to this request, but it just happened to neighbor it in memory What's interesting here in this case, it's the same injection. They just sent us what isn't that interesting What's more interesting and there are other instances where there is xml information leakage From the buffer overread from other devices that they may have been talking to recently So in this case At some point they were talking to a dlink dsl 27 30 you If you check that out, you can see that it is a popular item on a popular e-commerce website It's actually a choice item on that e-commerce website and it has 3100 readings. So For 1329 rupees you can buy this device and that's about 19 dollars us. I believe And you can inadvertently be a black hat proxy too So these are some of the top talkers or sorry some of the top injected test endpoints You can see there's akamai yahoo a few others in there That top one is clearly the standout winner the 89 39 105 12 and they're going to ip dot schtml That's a special page It returns your public facing ip address, which here i've clearly modified it and then this ubci eg plug That they use for some kind of identification i'm assuming So there's also a very large campaign being run against google. This is predominantly all the tls traffic It's very weird. I don't know what it is out of the 59 924 intercepted requests going across the tls sockets All of them 100 targeted google This is click fraud seo. I don't know what it is This is an example of a caught request. So they're searching for a sysco spark board factory reset We can see their accept language. We can see their cookies the user agent. They used all that good stuff We can see even they seem to be coming from dallas based on the information linkage in the url But I can't really confirm that Uh, also here we see the response. So we get a 200. Okay for their search. We see the cookies We would it's not here, but we would actually have the full page content and everything It's disabled in this case because that was a lot of log lines. I mean gigs and gigs and gigs at google pages So in in total they sent 57 237 search terms. There are no really clear patterns They're from all different geos that they target. They use a ton of different user agents And each request gets basically One search per session So, uh, you can see that top result there has only shown up 55 times out of 57 000 requests And it's just a search for the word samsung in quotes, which is weird Some of the funnier searches that were captured 72 hour deodorant antivirus download now Marlboro summer camp leather trousers outfit Fa fa fa fa slot hack. I don't even know what that is. I should probably google some of these to see But I haven't yet And like I said, they're they're very geographically distributing their stuff across the google platform There are domains in here that I don't even know what country they affiliated with So did you know there's a dot bj dot as dot jm Dot md dot ee you know, so They they're clearly targeting, you know, um google.com The most followed by co.uk, but still I there's so many that they're hitting. It's crazy This is the user agent profiles. So they sent 293 different user agents And then you can see there's almost normalized clusters of user agent distribution across the the abuse And these are some of the top talkers so It's it's not what you'd expect, right? You would I guess I mean I guess kind of it is what you'd expect if it's a single abuser, but the The nature of the queries almost make it seem organic. It doesn't seem like it has an abuse pattern It almost seems like real end users But then it's not real end users showing up and popping holes in this stuff They're all being ferried through a handful of top talkers and then you have your outliers If we look at the top 10 we see that world stream world stream world stream world stream ovh world stream ovh world stream ovh and a vast so Let me just put it this way if you work at world stream find me at the bar If you work at ovh find me at the bar If you work at a vast find me at the bar and I'll buy your drink If you tell me what the hell's going on there because I don't know why a vast would be showing up in this data set But there they are So some theories on this the queries to me seem too oddly human. They're in a bunch of different languages They're stuff like, you know, the best car insurance in Dallas, Fort Worth area Okay So it's too organic to be just purely automated abuse in my opinion Um, and I'm I'm not sure that the people that are using these proxies are aware that they're using them I have this Theory that it may be some kind of residential proxy reseller or some kind of you know Ultimate anonymous vpn service provider or something and these these people think that they're getting like these super secret You know high privacy stuff and I'm just sitting here in the middle reading their traffic, which is a problem So those are my theories. I'd love to hear more theories You'll also intercept some other stuff outside of tls Here for example are some spam messages that were being routed. These guys were injecting outlook servers and then You know, you can watch the entire interaction. You can watch as they send their their hello You can see as they confirm different addresses or deliverable and then they build their message and shoot it across You get to see all of that the good news here is that spam haas is doing god's work and stopping a lot of that abuse from actually succeeding um, this was just a fun finding from the Older data set so While this project was going on Belarus had a very tumultuous Political event where a bunch of people went out and protested the recent election and as a result Belarus shut down their internet to news and political websites and While that's going on suddenly I started seeing these guys popping up in UP and proxy So the top site was sb.by which is a news website and it looks like they were trying to Get to the registration and then solve some captures um The other was photo belta.by which is a stock imaging host. I think or something But they were actually doing command or not command injections sequel injections, which I found pretty funny And then the third one here is mail.rec.gov.by Um According to google translate. This is the central commission of the republic of belarus elections Or something along those lines and they were just trying to check their mail. It looks like and then on the bottom one here We've got a news outlet ont.by and then they're trying to get to what appears to be their exchange server So I just found that kind of interesting All right, so that's a lot of history a lot of observations, but now comes the cool part I'm open sourcing all of this So anybody that wants to take this stick it on the internet Play with it modify it whatever you want to do Have at it it's yours. Um, and this way we can all kind of share the fun and and see what's going on with these campaigns And if you find really cool stuff, I'd love to hear about it So with that open source announcement announcement, let's get some stuff out of the way First things first this project was for fun is for research. Um, and it was for me to practice my go-lang during covid um Second I apologize for my shitty code. I know it's shitty I've learned more go-lang since then and learned more design patterns in go-lang since then and I really Understand how shitty my code is. I'm sorry Uh, like I said, it was a research project. It's not commercial grade software Um, it served its purpose and it did well enough to serve that purpose and that's all I really needed out of it Yes, there are bugs. Thank you for noticing if you open an issue There's a great chance I'm not going to address it. Maybe someone else in the community will but this is not my top priority anymore Um, so I would encourage you to learn some go-lang and maybe submit a pull request instead If you'd like to fix that bug Yes, it's hacky I know I am a hacky developer. I'm not your enterprise leading Scrum running everything else developer. So it is what it is Uh, if you have ideas to fix or improve stuff It's open source have at it boss fork away send pull requests. Whatever I'm I'll likely accept a pull request I'll likely ignore your issue that you submit to the github robot story so, um Some ideas for improvements if you want to hit the ground running Logging could be improved content injection could be a thing Uh in a world where people are abusing this stuff I imagine that you could stick javascript in pages or you could tamper with cookies or you could inject Plugs of text that might be indexable that you could maybe turn up on a search engine later. I don't know. These are just some ideas I've had Uh, there is a memory leak I know um The run script actually restarts the buy in every area Restarts the binary every hour to get around this because I haven't had time to actually troubleshoot it Um, yes, it runs in screen. I regret nothing Feel free to properly demonize it if you'd like Um, this I think would be the biggest benefit if you randomize the ssdp banners And listen on multiple popular exposed upnp ports I have a feeling you're going to see a much more diverse set of attackers show up Uh, my findings may be myopic because I'm pretending to be a single device And that single device is what's being targeted by these people if you were to Diversify the the target that you paint for your attacker. It's possible. You will also diversify your findings Some additional ideas for improvement. Uh, the cert caching When I wrote this the cert caching was not taking in sni differences so It works on google because all google servers are just google but if you were to say Have an injection that pointed to someplace that was Uh, had multiple domains associated with it Your one cloned cert is only going to be the one that is aligned with that initial request So you could improve that by in this in the cert cache actually Using the sni value the domain name that was used when that cert was cloned Um improved tls handling and proxing like I said It was working it has stopped working Improving that would probably fix the problem Um improved cert cloning cloned more fields to better emulate the remote the the endpoint cert that you're trying to clone Improved air handling because I didn't really handle any errors. So anything is an improvement And improved basically everything else You can find most of the information you'll need in the readme file If there is anything I missed, please feel free to submit a pull request with the updates that you found when deploying this stuff It's written in golang, but it does have linux Dependencies so it will run on any any operating system so long as it's linux You can deploy a node in vps's very easily. You could also run it on raspberry pies or ojoids or anything else Just stick it on the dmz and you'll be good to go Typically you start to see abuse within the first 24 to 48 hours of deployment And it may be even lower than that So the last thing if you find something cool Please hit me up on linkedin and let me know about it. I'd love to hear if you Find new and interesting trends in some of your deployments And that wraps it up. So go grab the project Pull it down hack it up compile it deploy it Let me know what you find go have fun