Today we're taking a look at an offensive security phishing framework I've created called Redler.
We've got a live demo we're going to hop into shortly, but before that I've got a quick three slides I want to cover.
A little bit about me. My name is Matt Carrillo and I'm a Senior Cybersecurity Analyst at Shiner Downs.
We're a firm based out of Pittsburgh and Columbus offering a variety of security consulting services.
I've been with the company since early 2017, and most of my focus during that time has been performing
penetration testing and offensive services for clients.
Within our team, I sort of service the de facto developer when we need something built or edited,
although I don't have a formal software engineering background.
I've also been assigned several incident response cases, so although my focus is on the offensive side of security,
I do have some experience on the other side of the fence.
One of the areas I've spent the most time working in and developing for us is phishing, which we're here to talk about today.
So why Reddler? We've used multiple different phishing tools and platforms since I joined the team,
and with each of them, we felt there was probably something out there that better suited our needs.
Eventually we decided to delve into creating our own, which became Reddler, and these became the goals for the project.
One of our top priorities was the ability to be running and managing several phishing campaigns at once,
whether that be multiple phishing campaigns running off a single server, or campaigns running off of separate servers.
Also high on the list, the ability to chain templated webpages together in a way that mimics the user experience
on popular cloud email services where usernames and passwords are submitted on sequential webpages.
We think this is a must for phishing in today's environment.
We also have a need to be able to quickly add on to existing infrastructure when we need it,
and quickly tear it down when that gets burned.
In the event of one of our phishing servers getting burned and we tear it down,
we don't want to lose all of our phishing templates and data.
We wanted all data stored somewhere centralized that could manage other phishing servers
and perform remote actions for us, such as generating SSL certificates.
Encryption of sensitive data was also important, mostly revolving around phishing data,
such as user submitted form data and SMTP credentials.
On the payload delivery side, we also wanted an integrated way to be able to serve payloads
instead of exposing our C2 infrastructure by hosting our payload from our Cobalt Strike web server
or something similar to that.
And lastly, we also wanted a way to still be able to track information regarding our phishing targets,
such as IP addresses, user agents, but also click counts, opened email accounts,
because a lot of our clients still care about those statistics.
Last bit before we get over to the demonstration.
Redler is broken down into three parts, and this is how our environment is structured.
The Redler console is the main backend, written in Flask and Python,
which stores your templates, tracks your campaigns, and manages your remote phishing servers.
The client is a web interface written in Angular 7 that allows you to interact
with the exposed console endpoints via a GUI.
And I run the client and the console off the same server.
The last component are your Redler workers, which is another Python API that you run on separate servers.
Ideally, you can add as many workers to your phishing infrastructure as you require.
The workers are what actually runs your phishing web servers
and sends statistics and form data back to the console.
So we fire off this whole environment and then just open up the workers' web ports
to the internet for our phishing targets to hit.
Now let's transition over to the demo.
So we're here at the Redler login page, and you can see the web interface that I'm connected to
is running on winterphish.com off port 4200.
Down here in the console bar, you can see the Redler console I've specified we're going to be logging into
and connecting to is the same domain, but off port 5000.
So again, these are running on the same server, just different ports.
So go ahead and log in. We've got a bit of a Game of Thrones theme here, so we log in as Jon Snow.
And when you log in, you're first presented with the workspaces page.
We'll come back to this page in a minute. The first page I actually want to cover is the domains and servers page.
The domains and servers component is where you manage your Redler workers and your phishing domains.
On the server side, you can see I have three Redler workers connected with my console.
And ideally, you can integrate as many of these as you want with a single console.
In our production phishing environment, we're running quite a few of these.
For each worker on the table, there's a couple actions you can take.
You can check its status to make sure that worker to console and console to worker communications are working.
You can upload files to the worker and delete files off the worker.
Anything uploaded here gets copied over to the static folder of your web server.
So you can upload resource files here for your HTML templates or payloads to be served.
We can also check what ports are currently bound to on the worker.
So, if we're running a phishing campaign off of port 443, we'd see that here.
If a port is taken up, we'd want to phish off of something like 80.
You can actually be running campaigns in parallel off these workers.
You can have a campaign running on worker 2 on 443 and on 80.
Or you could have campaigns running on workers 1, 2, and 3 all off port 443.
Those can all be managed from a single interface here.
The API key up here actually has to be entered into a config file on the worker manually.
So, when the console goes to present campaign configs to the worker and gives it the HTML templates to host,
this API key is sent with it, and if it does not match, that kind of communication will fail.
On the reverse side, when the worker is sending data back to the console, statistics updates, clicks, opens, forms data,
the API key is sent from the worker to the console.
And again, if the API key does not match on either end, the communications will fail.
On the domain side, we can see the two domains I've configured for the purposes of the demo.
Domains are only usable if the domain resolves to one of the IP addresses of your Redlet workers over on the server side.
And once added to the table, there's a couple actions we can take again.
The refresh button will resolve the domain to an IP address and update the value shown here in the table,
and the green lock will generate SSL certs using Let's Encrypt for your domain.
We'll go ahead and do that for Bravo's Logistics here.
The certs have been successfully generated, and we can see that the certain key paths have been updated with the default paths of Let's Encrypt certs.
If you're not using Let's Encrypt for SSL certs, you can come in here and also specify the paths to your custom certain key in the interface here.
Next, we'll briefly cover the Users and Roles component.
This page is only accessible to users who have been assigned an administrator-type role.
And from here, you can add and delete users, reset passwords, and also change what roles users are assigned to.
In the Users table here, we can see the admin user and jsnow user have been assigned the Redler Admin role,
and the starly account has been assigned the Night's Watch role.
On the Roles side, you can add and delete roles, but also edit the permissions assigned to each role.
So the Redler Admin role here, which is an administrator role, it has the ability to view all the workspaces accessible via the console.
So you can delegate these just by unchecking and checking the boxes here.
And the Night's Watch role, which is a user-type role, only has access to two of the several workspaces available via the console.
So as an example, I use this feature all the time to delegate access to our interns,
to ensure that they only have access to the current engagements that they're working on, and not all of the projects that we're doing at that time.
Right now, there's only two role types. There's the administrator types and the user types.
And the differences between these are that the administrator roles get added automatically to all newly created workspaces,
and the administrator roles have the ability to access this Users and Roles page to perform administrative functions.
With that, let's move back over to the Workspaces page.
Workspaces are really just buckets that are there to help you organize your phishing engagements or projects.
Phishing templates and results, including statistics and credentials from one workspace, will not be viewable outside of that workspace.
The exception to this is the General workspace.
Any templates you add to the General workspace will be usable in campaigns within other workspaces,
although they will only be editable from the General workspace.
This workspace is really there just to help you declutter the rest of the interface.
So now let's enter our Casterly Rock workspace.
You can see a bunch of new tabs just appeared on the nav bar which contain this workspace's templates and data.
The Results page, which we're on now, shows all the statistics from our current and previous campaigns.
From here we can see all the campaigns in this workspace, filter the results by campaign, and drill down into the results.
Each of these result categories is exclusive, so users who have submitted creds do not also count in the clicked or opened category.
It is assumed that to submit creds the link was clicked and the email was opened.
The Download category tracks users who downloaded a payload or a file from your phishing site.
My team often doesn't send direct attachments, so instead we'll have our file download automatically from a web page.
Clicking on a category we can see targets who belong to it.
And going a little bit further, we can see information about each user, including the timestamps of different actions,
and the associated IPs and user agents.
Submitted form data appears down here in the Credential Vault.
Clicking a row we can see all of the form data submitted.
And there's also a couple graphs available for reporting.
That pretty much wraps up the results component.
Let's move on to our phishing templates and get ready to prep our new campaign.
The Emails component houses our email templates, and I've got a couple already loaded in here.
We'll go ahead and just pick one to edit.
So everything's edited via HTML on the back end, and you can preview it in iFrame here.
You can see we're working with a template that is dealing with email availability issues,
and some security changes have been made.
Just got to go log in and make sure that access has not been affected.
And we're impersonating MaesterPysel here, our maester of network communications.
You can see there's a couple of variables in here.
So we've got the firstName variable there, as well as a URL variable here.
And there's a couple more that are available for use in emails.
So the URL variable will just simply take users to your initial landing page.
The payload URL will take users directly to your hosted payload,
so this link should just simply download a file if you configure the campaign to use a payload when you set it up.
And the rest of the variables here, firstName, lastName, fullName, email, and ID,
are just going to be unique variables based on the recipient.
Email tracking is also on by default, and you can toggle this on and off.
This will simply include the 1x1 pixel image at the bottom of the email,
where if it's rendered, you can deduce that your target has opened the email.
The pages component is very similar to the email component,
and this is where you store your HTML templates for your phishing webpages.
I've got one template preloaded here in the Casterly Rock workspace,
but the login templates we're going to be using with our email availability scenario
are actually kept in the general workspace for now.
So let's backtrack over there so we can edit them.
And again, even though these two templates are only editable
in the pages component of the general workspace,
these will be available for selection with campaigns in any workspace.
So we've got our username and password pages here.
Let's pop these open just for a preview.
And this is actually one of the best features about Reddler,
is that you have the ability to chain up to four of your templated webpages together
during any one campaign.
So this can help you create a dynamic scenario
or accurately mimic the user experience for your particular targeted site.
Let's go in and edit one of these now.
So we can see this is the same HTML editor that the emails component has.
We've got the same iframe preview.
We've also got the ability to clone a site.
And we also can specify the trailing URL path that this specific webpage is going to be hosted on.
Again, we've also got several variables that can be used.
So the next URL variable is the variable you're going to be using the most.
And this is how you tie your templated webpages together.
So down in our form here on the username page,
we can see the action attribute is just set to the next URL variable.
This will get dynamically replaced at runtime
with the trailing URL path of your second page in the sequence.
So that will be replaced with this value here
and bring users over to the password page when they submit their username.
The payload URL variable is the same as the payload URL variable available in the emails.
And again, this will let you use a button or a hyperlink
to directly download the specified payload configured with your campaign.
The serve payload variable is a little bit different from the payload URL variable
in that you can just include this anywhere in your HTML template.
And it will get replaced at runtime with a HTML meta tag, kind of like down here.
And when someone browses to your page,
it should automatically drop your specified payload to their file system
without any type of button or hyperlink click.
And for both of these, when using either of these,
the tracking integrity is maintained.
So the specific user ID of whoever is browsing your site at that moment
will be inserted here in the payload URL so you can continue to track
who exactly is downloading your payloads.
The final three variables down here, login.fmt, username, and email,
are there to help you mimic user experiences and do sort of a variable pass-through.
If we check our password page here,
we can see we've got the login.fmt value specified above our enter password header.
And this will let us grab the value of an input box with the login.fmt name
from the previous page's form submission and display it here.
If we look back at our username page,
the input box we're going to be entering data into has the name attribute set to login.fmt.
Whatever data the user submits on this page here will be displayed on the second page
to help mimic common login experiences.
So we're halfway through the campaign makeup at this point, taking a look at emails and pages.
All we've got left is target lists and profiles before we're ready to send.
We'll go back to our Caskly Rock workspace at this point and get our target list prepped.
We'll make a new list, and you can either add users one by one here
by adding their information in this line and clicking the plus button,
or you can upload a CSV file. So I'm just going to do that to save some time.
We'll call the list Lannisters.
And you can see this was filled out already with first name, last name, and email.
Email is the only required value. First and last name are available though
if you want to be able to reference the fname and lname type variables in your email template.
We'll go ahead and create this, and this is going to be who we're sending to when we kick off our campaign.
Profiles are our last required component to start a campaign.
Similar to when we took a look at Pages, the profile we want to use is being housed in the General workspace.
Instead of navigating back to the General workspace and looking at it there,
I'm actually going to import it over to our current Caskly Rock workspace.
So now our profile has been imported to our current workspace.
We can take a look at it and make some edits.
We can also change how it looks like when a user receives it.
Down here you can see we've got the SMTP host, port, username, and password.
We're also specifying we're going to be using a DLS connection.
Save this in the test email to make sure that our profile is working.
Great, so now that our profile is successfully working,
we're ready to go generate a new campaign.
The Campaigns component shows us our three previously run campaigns.
All of these are completed, so none of them are active anymore.
We'll go ahead and create a new campaign up here.
The first set of options we're presented with are our hosting options.
We'll select our domain that is going to host our phishing site, westerosport.com.
We can see the IP that that domain resolves to.
We'll also select our server, which is going to be worker1, also the IP address that our domain resolves to.
If we try and select another worker that has a different IP address and continue,
we will be forbidden from doing so.
We'll go ahead and select worker1.
We can also specify the port that we want to host the campaign off of, as well as whether or not we want to use SSL.
This will reference the cert path supplied on the domains and servers page
for the chosen domain.
Moving on to our scenario options, we'll go ahead and specify a campaign name.
And select our email template.
We'll do our cloud email update.
Optionally, you can also attach a file here. I'm not going to do so for this scenario, but it's there.
This is what I was mentioning earlier when I said that you can
choose to specify up to four pages per campaign
to be used in sequence. We'll go ahead here and select our username page.
And then sequentially our password page, so that once
the user has submitted a username, they are presented with our password page.
You can take this a step further and show a success page or something like that.
I've never used all four pages here, but the option is there if you have
a complicated scenario that requires something like that.
Optionally, we can also specify a redirect URL. So after our last form
is submitted, we can take them to the actual login page that we've cloned.
I'll just go ahead and specify here, schneiderdowns.com.
And also optionally, we can select some payload config.
So we can pick a payload file that we've uploaded to Worker 1 previously.
Also specify the trailing URL path that that payload will be hosted on.
I'm not going to do that here. We'll run through another scenario in which we do configure
these, but this is what the payload URL variable that you can use
in your email templates and your page templates is going to link to eventually.
And last, we have our sending options.
We'll pick our list that contains our target email addresses, Lannisters.
We'll pick our sending profile, so we'll go with the PyCell profile
that will be imported into the Casterly Rock workspace. And optionally, we can also specify
some batch sending. We can send two emails
through at a rate of... on an interval of every 60 minutes
here, if we don't want to blast our target with all emails at once. If we leave these configs
blank, all emails will just be sent at one time. Also
optionally, we can choose to start the campaign in the future. I'm not going to do
that here. If you leave this blank, it'll start right now. And with that
we'll go ahead and launch our campaign.
So we'll give it a couple seconds here. We can see our campaign has been added to the
campaigns page. And we'll give it a moment
and when we click refresh, we should see that this campaign status changes
to active. Okay, there we go. We can see we've also got an option
now to kill a campaign and end it.
We'll head over to the results component again and just filter down to our
newly run campaigns. We can see all four emails have been sent. All four
are currently unopened. We'll browse out to one of the inboxes here
and log in. Let's simulate someone getting phished.
We'll log into Searcy here and we can see we've got
an email from MasterPycel. We trust everything from MasterPycel.
We'll go ahead and we'll download the external images. We'll click the link
and we're presented with our sign-in page here. So we can see we're at
westerosupport.com with the trailing URL path we provided and also
Searcy's unique ID. We'll go ahead
provide our email address. We can see
our variable passed through here to the second page. We'll go ahead and enter
our password in. And we're hit with our redirect.
So let's go back over to
the UI here and we can see the statistics
are actually already updated. We've got a little information on Searcy.
So we can see the time stamps of everything, all the actions she took
here, as well as the IP address that's all coming from the user agent.
And if we come down here, we can
see the username and password submitted.
So while our cred harvesting campaign is running, I've got a couple more templates rigged up
to do payload phish that should automatically drop a file to the
user's file system when they browse out to the page. Let's go ahead and configure that
to run real quick. Use brawlsuggestics.com
We'll run that off of Red Alert Worker number 2.
Again, we'll use 443 and SSL.
Go ahead and name our campaign. Select our email. And again, I'm not going to
attach the payload directly to the email. I'm going to
specify it down here in the optional payload settings.
And we'll send it out to the Lannisters. We'll use our
Braavos Logistics profile and we'll just leave all this blank to send all the emails out at
once. We'll give it a couple seconds here and we should
see the campaign flip to active on our DefCon Worker 2.
There we go.
Come back over here. Filter down our results to just this campaign.
We've got one email left to send.
All emails have been sent out. Come back to
Cersei's inbox. Check her email. She's got an invoice here from Braavos
Logistics. Download the external images.
So, building department is waiting to process the order before it can be shipped to Casterly Rock.
We'll go ahead and download our invoice so we can fill it out.
Come out to the page here and our invoice will automatically download.
We'll head back to Red Alert.
Refresh our stats. We can see we've got the download track on
Cersei. And we can see all the information on where that's
coming from. With our campaigns having run
their course, we can come in here. We'll go ahead and kill both of these campaigns.
Take them down. The page should no longer refresh.
And if we come back to our domains and
service page, we check Worker 1 and Worker 2. We should see that no
campaigns are running on ports 443.
That wraps up our demo. I'll flip back to the PowerPoint
briefly here just to cover a couple potential to-dos.
A couple things we're thinking about adding into Red Alert would be the ability to relay
emails through a specified Red Alert worker. But the way things are currently set
up, your Red Alert console is always going to be
the IP address reaching out to the specified
SMTP server in your profile configs and sending emails
that way. So if something were to happen to the reputation of your console's
IP address, it could potentially affect its ability to send emails.
Adding in the ability to specify a worker to send the emails for your console
would add a little bit more redundancy and
work for that burnability of the workers.
Another thing would be to potentially add in a mechanism
to direct users to different webpages
or scenarios based on the visiting user agent. So say you're potentially running
a payload phishing campaign and a user
visits your site from a mobile device.
Detecting that via the user agent and then potentially redirecting
these mobile users to a credential phishing attack
would be something that we'd like to add in in the future.
Also the ability to specify IPs associated with
products such as Microsoft, ATP,
Proofpoint, Mimecast, anything that may be going out and probing some of your phishing sites
to determine if it's got malicious files being served or if
it's got credential harvesting forms, anything like that.
Putting specified IPs or ranges in and then redirecting these
IPs to harmless sites. Kind of along that line
also would be delaying the weaponization of your hosted payload.
So when you go in and you select the payload you want to host off your worker and the trailing URL path
potentially replacing that with a dummy payload that could serve for the
first 45 seconds or 5 minutes after runtime.
And then after that time has passed, anybody browsing to it
and any hits for that link will actually drop your real
malicious payload. And lastly would be the
bypass that's out there for Office 365 Safe Links. Using relative
URL paths and the HTML base tag to specify your
domain instead of using absolute URLs all over your email.
I'm not sure if this still works. I know this was a thing quite a while ago.
Something that would be real easy to add into Redler.
And that's the end of the presentation. I've got contact
info there. As of the time I'm recording this, the GitHub
repositories are not public yet. They will be in the very near future.
And this is something that we're definitely open to community support
on as well once this is public. So thanks everybody
for watching and good luck phishing.