- Welcome to my talk.
This is UPnProxyPot,
fake the funk, become a blackout proxy,
man in the middle their TLS and scrape the wire.
Before we begin. I'm Chad seaman,
but around here at DefCon you can just call me d1rt.
I am part of the Akamai SIRT team.
I'm actually a team lead and senior engineer on that team.
For those of you unfamiliar with the SIRT 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 going to 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 had been widely vulnerable in 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 UPnProxy research and campaigns conducted by me
and finally UPnProxyPot, 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 LAN.
Uses broadcast addressing with HTTP over UDP.
It essentially allows machines on a LAN
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 LAN.
It's good old HTTP and SOAP.
SOAP as an XML.
It lets machines on a LAN
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 X-Box to go forward and say,
"Hey, poke a hole in the firewall,
send everything on UDP 1, 2, 3, 4, over to me."
So what is wrong with these technologies?
Well, for SSDP, IOT devices are notoriously bad
at deploying this correctly.
The same is true for UPnP.
It's built for the LAN,
but they stick it on the WAN
just because, I don't know, just cause.
It was a reflected DDoS vector.
Up and coming, most popular, MVP, king of the hill,
whatever you want to call it, in 2014 to 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.
We're still finding this bullshit everywhere.
Older products are still on the internet,
amazingly "newer" products and new is there in quotes,
but 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 old problems.
So UPnP, Universal Plug And Play,
once again, built for the LAN,
but they seem to just love to stick
this stuff on the WAN too.
It treats the LAN 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 LAN, it's a little bit of a problem.
It just does whatever
it's 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.
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 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 2003, Björn Stickler.
He came public with a Netgear UPnP information disclosure.
A couple of years later,
I'm going to slaughter this guy's name,
Armijn Hemel, I think, in 2006,
gave a talk at the same conference
and he launched a website called UPnPhacks.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 I went ahead and remoted into my home network
and disabled UPnP from the talk,
while I was in the talk from my phone.
So, a brief history of UPnProxy.
So UPnProxy, in 2014, like I said
SSDP is the new up and coming DDoS specter.
We're starting to see it abused pretty widely.
We, Akamai SIRT, at that time we were known as PLX SIRT,
are asked to write about it,
start digging into it.
Put it on an advisory and all that good stuff.
So in 2015, this was happening at the end of 2014.
In early 2015,
the SSDP research leads me to discover UPnP
and it kind of turns on that 2011 talk in my head.
And I'm like,
"Oh man, I remember this being like a shitshow."
So in 2016, I decide 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 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.168.0.1.
We changed that to the public facing IP address
that we found UPnP responding on.
In our SOAP payload we set that port 5.5.5.5
is going to point into 192.168.0.1
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 80's filtered, you couldn't get to it.
But once I opened TCP 5.5.5.5
and then I hit it in a browser,
I am greeted with the admin login page.
So that's a little bit of a problem
being able to get around the firewall that easy.
(large sigh)
As I'm doing this research in September, 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 Mirai.
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 data set
that I had from my decade of 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 Mirai botnet
has nothing to do with Mirai.
It's just that shitty devices are shitty.
And if it's comprizable one way,
it's probably comprizable 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 can 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 pointed to DNS servers,
they pointed to Akamai CDN servers.
They've 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 Mirai botnet and huge DDoS.
So while I'm investigating that,
I accidentally uncover the UPnProxy stuff,
but I'm too busy dealing with this botnet.
2017, things start to calm down.
Mirai, at least I have tooling
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 UPnP daemons.
This is when we uncover the UPnProxy campaigns.
So UPnProxy uncovered by the numbers.
There were 4.8 million SSDP responders in that data set.
765,000 had exposed UPnP, it's roughly 16%.
Of those, 65,000 were actively injected with UPnP entries.
That's 9% of the total vulnerable population
and 1.3% of the total responders.
Of those 17,599 unique end points
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 HTTPS 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?"
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 Symantec 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 UPnProxy instances
and they were chaining them together.
So they would log into their VPS.
They would inject a proxy route
that pointed to another UPnProxy 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 times you'll have these lists of known proxies,
known end points, TOR, et cetera.
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 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 end points.
So it's a different structure,
different strategy of building that chaining.
But the chaining exists.
And I thought that was pretty cool.
So we find all this stuff,
but it's not super widespread.
I'm just kidding. It's everywhere.
So there are 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% of these based on information leaks.
And those information leaks
weren't just what came from the UPnP daemon.
Sure, it helped a ton because it's a super chatty...
It 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 could only get about 24%.
So that is quite a considerable amount.
73 brands, 400 models is a nice chunk,
but you gotta remember
that there's 76% that we couldn't even identify.
So, who knows what they are.
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 cared.
So I'll take that as a win.
The research did get some industry attention
through some trust groups and work groups and stuff.
Did get elevated and passed along.
And it was ultimately used to help some ISPs
support the case internally
for clean up and sanitation efforts.
So, progress is made behind the scenes.
Some networks start filtering SSDP, that's all good.
You'll you'll see the result of that
in the next couple of slides.
Ultimately I get an email from a journalist,
she's doing some work and she was recording this new show.
Her name's Justine Underhill.
And she wanted to talk to me about UPnProxy
because the episode she was recording was on IOT
and security and everything else.
So while we're recording this video,
I decided that 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 show you."
So I pull out the laptop,
jump on the internet
run ZMAP 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 wasn't in the previous scans."
And this is how I accidentally discovered
the EternalSilence stuff.
Which it was cool,
cause 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 JSON.
You can see that they are targeting IPs
inside the LAN 192.1.68.10 space,
probably from the information leak from the SSDP banner.
And then so like there on 166,
you can see that they tried to open
a port forward to 139 in port 445.
So they're injecting routes into the LAN space
and they are targeting Samba or SMB.
We named it EternalSilence because Samba and SMB
are clearly being targeted by EternalBlue,
pretty heavily at that point
and the Spanish there,
in the Newport mapping description there's some Spanish,
and I am terrible at Spanish.
So, my gringo Spanish is, "Galleta silenciosa."
Go ahead and laugh at me,
but it roughly translates to, "Silent cookie."
So UPnP EternalSilence 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 UPnP.
45,000 had active, EternalSilence injections.
There's no way to really know what they were up to,
but based on what they were targeting,
the EternalBlue link is an educated guess.
And that educated guest 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'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 of 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 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 port 25,
we assume it's spam, but we have no idea.
They could be dropping 0days against,
you know, SMTP servers.
No clue.
So we need to fix that.
And that's where UPnProxyPot enters the fight if you will.
So what is UPnProxyPot?
The 50,000 foot view.
It listens for SSDP probes
and it directs attackers into a fake UPnP instance.
The UPnP 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.
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 disc.
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 Golang and bash.
So, SSTP emulation.
The SSDP response that is currently in the project
was lifted directly from the most abused device
that we discovered during the UPnProxy research.
It stored a flat file on 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 UPnP daemon
is listening on, this is what the attackers pivot on.
So you will need to change the listening port in code
that the UPnP daemon listens on.
I didn't have a configuration file set up
when I wrote this in my initial thing.
It's an improvement that could be made.
UPnP emulation.
So the UPnP responses are lifted also
from those same most abused devices.
All the HTML XML is stored in flat files,
updating them requires no code changes.
UPnP emulation serves basic files, handles NAT interactions.
The attackers applied 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 supply data.
So that these responses use standard printf formatting.
So if you need to change your thing
and the attacker supplied port
needs to be in this chunk of XML,
you can just put the %d and it'll be there.
So, on the fly proxy.
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 UPnP.
We parse them and then create a session of sorts.
And then we scrape and log plain text
across the proxied session in both directions.
If they're proxying to TCP 443, it's a special use case
and we assume that connection is a TLS connection
and we do some special man in the middle link there.
So, stripping TLS.
And this is a hard slide to read.
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 SIRTs.
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 ClientHello.
We then go forward to the injected endpoint
and we get the SIRT with the respect of SNI
that was provided in the ClientHello.
We copied the subject field from the remote SIRT
and we mirror it into a self-signed clone SIRT.
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 PCAPing.
The project uses gopacket.
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 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 favorite, you know,
PCAP packet muncher is.
Wireshark, TCPdump, whatever.
If you run out of disc 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, (large sigh)
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.
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 of 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 proxies.
They actually come and do some testing.
So injections,
they first come and they insert 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 M-SEARCH banner.
We respond with our SSDP response here,
and you see that we point them to
192.168.0.1 on port 2048,
and then etc/linuxigd/gatedesc.xml.
We see them come back within the same second
and they then request that.
You can see SSDP 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 WAN port 22280.
It's a TCP socket,
and any traffic received on that
is going to be redirected to port 80
on the host at 74.6.231.21.
You can see down there,
the new port mapping description
kind of mirrors the external port
that they use that's sync and then a number.
And then the new lease duration is 600 seconds.
So, 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 to 280.
Everything up there between the curly braces
is the proxy configuration.
We can see the source.
We can see where ultimately they're going to point to.
So 93.190.139.76 on port 57388
is going to send traffic to 74.62.31.21 on port 80.
Ultimately we intercept a GET request
to Yahoo with no header.
So it's super easy to spot.
And Yahoo, because they moved 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 send us.
Which 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 D-link DSL, 2730U.
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 3,100 ratings.
So for 1,329 rupees, you can buy this device.
And that's about $19 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 end points.
So 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.shtml.
That's a special page.
It returns your public facing IP address,
which here I've clearly modified it.
And then this UBC IEG 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 Cisco 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 leakage in the URL.
But I can't really confirm that.
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 of Google pages.
So in total, they sent 57,237 searched 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 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, fafafa 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 very geographically
distributing their stuff across the Google platform.
There are domains in here
that I don't even know what country they're affiliated with.
So did you know, there's a .bj,
.as, .jm, .md, .ee?
You know, so they they're clearly targeting
google.com the most, followed by co.uk.
But still 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 users
and distribution across the abuse.
And these are some of the top talkers.
So, it's not what you'd expect, right?
You would, I guess, I mean,
I guess it is what you'd expect
if it's a single abuser.
But 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 Worldstream, Worldstream, Worldstream,
Worldstream, OVH, Worldstream, OVH,
Worldstream, OVH and Avast.
So let me just put it this way.
If you work at Worldstream, find me at the bar.
If you work at OVH, find me at the bar.
If you work at Avast find me at the bar
and I'll buy your drink,
if you tell me what the hell is going on there.
Cause I don't know why Avast
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.
And 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 ultimate anonymous
VPN service provider or something.
And these people think that they're getting
these super secret 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 can watch the entire interaction.
You can watch as they send their, their hello.
You can see as they confirm
different addresses are deliverable
and then they build their message and shoot it across.
You get to see all of that.
The good news here is that Spamhaus is doing God's work
and stopping a lot of that abuse from actually succeeding.
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 UK in 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 CAPTCHAs.
The other was photobelta.by
which is a stock imaging host, I think, or something.
But they were actually doing command,
not command, injection, SQL injections.
Which I found pretty funny.
And then the third one here is mail.rec.gov.by.
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 it comes to 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.
And this way we can all kind of share the fun
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,
let's get some stuff out of the way.
First things first,
this project was for fun, is for research
and it was for me to practice my Golang during COVID.
Second, I apologize for my shitty code.
I know it's shitty.
I've learned more Golang since then
and learned more design patterns in Golang since then.
And I really understand how shitty my code is.
I'm sorry.
Like I said, it was a research project.
It's not commercial grade software.
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.
So I would encourage you to learn some Golang
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.
If you have ideas to fix or improve stuff,
it's open source.
Have at it, hoss. Fork away.
Send pull requests, whatever.
I'll likely accept a pull request.
I will likely ignore your issue
that you submit to the GitHub repository.
So, some ideas for improvements.
If you want to hit the ground running.
Logging could be improved.
Content injection could be a thing.
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 texts
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.
There is a memory leak. I know.
The run script actually
restarts the binary every hour
to get around this because I haven't had time
to actually troubleshoot it.
Yes, it runs in screen.
I regret nothing.
Feel free to properly daemonize it if you'd like.
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.
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 target
that you paint for your attacker.
It's possible you will also diversify your findings.
Some additional ideas for improvement.
The SIRT caching, when I wrote this,
the SIRT 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 multiple domains associated with it,
you're one clone SIRT is only going to be
the one that is aligned with that initial request.
So you could improve that by in the SIRT cache,
actually using the SNI value,
the domain name that was used when that SIRT was cloned.
Improved TLS handling and proxying, like I said.
It was working. It has stopped working.
Improving that would probably fix the problem.
Improved SIRT cloning.
Clone more fields to better emulate the remote,
the endpoint SIRT that you're trying to clone.
Improved error handling.
Cause 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 operating system
so long as it's Linux.
You can deploy a node in VPSs very easily.
You could also run it on Raspberry Pies
or ODroids 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.