[00:01.160 --> 00:06.180]  Today we're taking a look at an offensive security phishing framework I've created called Redler.
[00:06.420 --> 00:11.480]  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.
[00:12.580 --> 00:18.360]  A little bit about me. My name is Matt Carrillo and I'm a Senior Cybersecurity Analyst at Shiner Downs.
[00:18.360 --> 00:23.200]  We're a firm based out of Pittsburgh and Columbus offering a variety of security consulting services.
[00:23.620 --> 00:28.520]  I've been with the company since early 2017, and most of my focus during that time has been performing
[00:28.520 --> 00:31.600]  penetration testing and offensive services for clients.
[00:32.060 --> 00:36.140]  Within our team, I sort of service the de facto developer when we need something built or edited,
[00:36.140 --> 00:38.900]  although I don't have a formal software engineering background.
[00:39.580 --> 00:44.820]  I've also been assigned several incident response cases, so although my focus is on the offensive side of security,
[00:44.820 --> 00:47.420]  I do have some experience on the other side of the fence.
[00:48.460 --> 00:54.240]  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.
[00:55.960 --> 01:01.200]  So why Reddler? We've used multiple different phishing tools and platforms since I joined the team,
[01:01.200 --> 01:05.380]  and with each of them, we felt there was probably something out there that better suited our needs.
[01:05.620 --> 01:11.360]  Eventually we decided to delve into creating our own, which became Reddler, and these became the goals for the project.
[01:12.840 --> 01:17.980]  One of our top priorities was the ability to be running and managing several phishing campaigns at once,
[01:17.980 --> 01:24.020]  whether that be multiple phishing campaigns running off a single server, or campaigns running off of separate servers.
[01:24.240 --> 01:31.180]  Also high on the list, the ability to chain templated webpages together in a way that mimics the user experience
[01:31.180 --> 01:36.860]  on popular cloud email services where usernames and passwords are submitted on sequential webpages.
[01:37.080 --> 01:39.840]  We think this is a must for phishing in today's environment.
[01:40.820 --> 01:45.840]  We also have a need to be able to quickly add on to existing infrastructure when we need it,
[01:45.840 --> 01:48.440]  and quickly tear it down when that gets burned.
[01:48.440 --> 01:52.620]  In the event of one of our phishing servers getting burned and we tear it down,
[01:52.620 --> 01:55.320]  we don't want to lose all of our phishing templates and data.
[01:55.320 --> 01:59.500]  We wanted all data stored somewhere centralized that could manage other phishing servers
[01:59.500 --> 02:03.720]  and perform remote actions for us, such as generating SSL certificates.
[02:05.280 --> 02:10.040]  Encryption of sensitive data was also important, mostly revolving around phishing data,
[02:10.040 --> 02:14.280]  such as user submitted form data and SMTP credentials.
[02:15.260 --> 02:20.420]  On the payload delivery side, we also wanted an integrated way to be able to serve payloads
[02:20.420 --> 02:25.400]  instead of exposing our C2 infrastructure by hosting our payload from our Cobalt Strike web server
[02:25.400 --> 02:27.320]  or something similar to that.
[02:27.960 --> 02:32.840]  And lastly, we also wanted a way to still be able to track information regarding our phishing targets,
[02:32.840 --> 02:37.360]  such as IP addresses, user agents, but also click counts, opened email accounts,
[02:37.360 --> 02:40.300]  because a lot of our clients still care about those statistics.
[02:41.540 --> 02:44.560]  Last bit before we get over to the demonstration.
[02:44.880 --> 02:48.860]  Redler is broken down into three parts, and this is how our environment is structured.
[02:49.140 --> 02:54.000]  The Redler console is the main backend, written in Flask and Python,
[02:54.000 --> 02:59.340]  which stores your templates, tracks your campaigns, and manages your remote phishing servers.
[03:00.040 --> 03:04.500]  The client is a web interface written in Angular 7 that allows you to interact
[03:04.500 --> 03:07.640]  with the exposed console endpoints via a GUI.
[03:07.640 --> 03:11.320]  And I run the client and the console off the same server.
[03:12.100 --> 03:18.120]  The last component are your Redler workers, which is another Python API that you run on separate servers.
[03:18.220 --> 03:22.160]  Ideally, you can add as many workers to your phishing infrastructure as you require.
[03:22.160 --> 03:24.560]  The workers are what actually runs your phishing web servers
[03:24.560 --> 03:27.740]  and sends statistics and form data back to the console.
[03:28.140 --> 03:31.940]  So we fire off this whole environment and then just open up the workers' web ports
[03:31.940 --> 03:34.420]  to the internet for our phishing targets to hit.
[03:36.360 --> 03:39.040]  Now let's transition over to the demo.
[03:39.560 --> 03:44.280]  So we're here at the Redler login page, and you can see the web interface that I'm connected to
[03:44.280 --> 03:47.440]  is running on winterphish.com off port 4200.
[03:47.900 --> 03:53.180]  Down here in the console bar, you can see the Redler console I've specified we're going to be logging into
[03:53.180 --> 03:57.180]  and connecting to is the same domain, but off port 5000.
[03:57.180 --> 04:00.300]  So again, these are running on the same server, just different ports.
[04:00.300 --> 04:05.720]  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.
[04:06.620 --> 04:09.740]  And when you log in, you're first presented with the workspaces page.
[04:09.740 --> 04:15.300]  We'll come back to this page in a minute. The first page I actually want to cover is the domains and servers page.
[04:15.860 --> 04:20.360]  The domains and servers component is where you manage your Redler workers and your phishing domains.
[04:20.560 --> 04:24.820]  On the server side, you can see I have three Redler workers connected with my console.
[04:25.080 --> 04:29.160]  And ideally, you can integrate as many of these as you want with a single console.
[04:29.160 --> 04:32.180]  In our production phishing environment, we're running quite a few of these.
[04:32.580 --> 04:35.860]  For each worker on the table, there's a couple actions you can take.
[04:35.860 --> 04:41.820]  You can check its status to make sure that worker to console and console to worker communications are working.
[04:42.200 --> 04:47.140]  You can upload files to the worker and delete files off the worker.
[04:47.140 --> 04:51.980]  Anything uploaded here gets copied over to the static folder of your web server.
[04:52.100 --> 04:56.540]  So you can upload resource files here for your HTML templates or payloads to be served.
[04:57.780 --> 05:02.760]  We can also check what ports are currently bound to on the worker.
[05:02.760 --> 05:08.400]  So, if we're running a phishing campaign off of port 443, we'd see that here.
[05:08.400 --> 05:12.060]  If a port is taken up, we'd want to phish off of something like 80.
[05:12.780 --> 05:17.600]  You can actually be running campaigns in parallel off these workers.
[05:17.600 --> 05:22.500]  You can have a campaign running on worker 2 on 443 and on 80.
[05:22.500 --> 05:27.160]  Or you could have campaigns running on workers 1, 2, and 3 all off port 443.
[05:27.160 --> 05:29.820]  Those can all be managed from a single interface here.
[05:30.740 --> 05:37.380]  The API key up here actually has to be entered into a config file on the worker manually.
[05:37.520 --> 05:45.580]  So, when the console goes to present campaign configs to the worker and gives it the HTML templates to host,
[05:46.540 --> 05:51.660]  this API key is sent with it, and if it does not match, that kind of communication will fail.
[05:51.660 --> 05:59.180]  On the reverse side, when the worker is sending data back to the console, statistics updates, clicks, opens, forms data,
[05:59.180 --> 06:01.820]  the API key is sent from the worker to the console.
[06:01.940 --> 06:06.000]  And again, if the API key does not match on either end, the communications will fail.
[06:06.620 --> 06:11.840]  On the domain side, we can see the two domains I've configured for the purposes of the demo.
[06:12.240 --> 06:19.000]  Domains are only usable if the domain resolves to one of the IP addresses of your Redlet workers over on the server side.
[06:19.000 --> 06:23.060]  And once added to the table, there's a couple actions we can take again.
[06:23.180 --> 06:28.360]  The refresh button will resolve the domain to an IP address and update the value shown here in the table,
[06:28.360 --> 06:33.040]  and the green lock will generate SSL certs using Let's Encrypt for your domain.
[06:33.080 --> 06:35.940]  We'll go ahead and do that for Bravo's Logistics here.
[06:44.580 --> 06:53.120]  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.
[06:53.120 --> 07:02.040]  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.
[07:04.360 --> 07:08.160]  Next, we'll briefly cover the Users and Roles component.
[07:08.460 --> 07:14.600]  This page is only accessible to users who have been assigned an administrator-type role.
[07:14.780 --> 07:22.180]  And from here, you can add and delete users, reset passwords, and also change what roles users are assigned to.
[07:22.180 --> 07:29.320]  In the Users table here, we can see the admin user and jsnow user have been assigned the Redler Admin role,
[07:29.320 --> 07:33.320]  and the starly account has been assigned the Night's Watch role.
[07:34.000 --> 07:39.780]  On the Roles side, you can add and delete roles, but also edit the permissions assigned to each role.
[07:40.200 --> 07:50.440]  So the Redler Admin role here, which is an administrator role, it has the ability to view all the workspaces accessible via the console.
[07:50.440 --> 07:55.100]  So you can delegate these just by unchecking and checking the boxes here.
[07:55.660 --> 08:04.220]  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.
[08:04.460 --> 08:09.340]  So as an example, I use this feature all the time to delegate access to our interns,
[08:09.340 --> 08:16.780]  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.
[08:18.780 --> 08:25.000]  Right now, there's only two role types. There's the administrator types and the user types.
[08:25.100 --> 08:32.160]  And the differences between these are that the administrator roles get added automatically to all newly created workspaces,
[08:32.160 --> 08:38.580]  and the administrator roles have the ability to access this Users and Roles page to perform administrative functions.
[08:39.620 --> 08:43.220]  With that, let's move back over to the Workspaces page.
[08:43.960 --> 08:49.100]  Workspaces are really just buckets that are there to help you organize your phishing engagements or projects.
[08:49.100 --> 08:56.320]  Phishing templates and results, including statistics and credentials from one workspace, will not be viewable outside of that workspace.
[08:56.480 --> 08:59.300]  The exception to this is the General workspace.
[08:59.440 --> 09:04.420]  Any templates you add to the General workspace will be usable in campaigns within other workspaces,
[09:04.420 --> 09:07.280]  although they will only be editable from the General workspace.
[09:07.380 --> 09:11.260]  This workspace is really there just to help you declutter the rest of the interface.
[09:11.900 --> 09:15.640]  So now let's enter our Casterly Rock workspace.
[09:16.900 --> 09:23.060]  You can see a bunch of new tabs just appeared on the nav bar which contain this workspace's templates and data.
[09:23.200 --> 09:28.660]  The Results page, which we're on now, shows all the statistics from our current and previous campaigns.
[09:28.820 --> 09:36.660]  From here we can see all the campaigns in this workspace, filter the results by campaign, and drill down into the results.
[09:40.110 --> 09:47.470]  Each of these result categories is exclusive, so users who have submitted creds do not also count in the clicked or opened category.
[09:47.670 --> 09:51.870]  It is assumed that to submit creds the link was clicked and the email was opened.
[09:52.130 --> 09:57.630]  The Download category tracks users who downloaded a payload or a file from your phishing site.
[09:57.810 --> 10:03.570]  My team often doesn't send direct attachments, so instead we'll have our file download automatically from a web page.
[10:03.810 --> 10:07.070]  Clicking on a category we can see targets who belong to it.
[10:07.830 --> 10:14.670]  And going a little bit further, we can see information about each user, including the timestamps of different actions,
[10:14.670 --> 10:17.810]  and the associated IPs and user agents.
[10:21.620 --> 10:24.980]  Submitted form data appears down here in the Credential Vault.
[10:24.980 --> 10:27.920]  Clicking a row we can see all of the form data submitted.
[10:30.340 --> 10:33.800]  And there's also a couple graphs available for reporting.
[10:37.840 --> 10:40.900]  That pretty much wraps up the results component.
[10:40.900 --> 10:44.440]  Let's move on to our phishing templates and get ready to prep our new campaign.
[10:45.320 --> 10:50.180]  The Emails component houses our email templates, and I've got a couple already loaded in here.
[10:50.180 --> 10:52.400]  We'll go ahead and just pick one to edit.
[10:53.680 --> 10:59.540]  So everything's edited via HTML on the back end, and you can preview it in iFrame here.
[10:59.580 --> 11:06.300]  You can see we're working with a template that is dealing with email availability issues,
[11:06.300 --> 11:07.960]  and some security changes have been made.
[11:07.960 --> 11:11.260]  Just got to go log in and make sure that access has not been affected.
[11:11.260 --> 11:15.840]  And we're impersonating MaesterPysel here, our maester of network communications.
[11:15.880 --> 11:17.500]  You can see there's a couple of variables in here.
[11:17.500 --> 11:23.400]  So we've got the firstName variable there, as well as a URL variable here.
[11:24.000 --> 11:27.680]  And there's a couple more that are available for use in emails.
[11:27.680 --> 11:32.680]  So the URL variable will just simply take users to your initial landing page.
[11:32.680 --> 11:37.220]  The payload URL will take users directly to your hosted payload,
[11:37.220 --> 11:43.140]  so this link should just simply download a file if you configure the campaign to use a payload when you set it up.
[11:43.260 --> 11:48.100]  And the rest of the variables here, firstName, lastName, fullName, email, and ID,
[11:48.100 --> 11:52.360]  are just going to be unique variables based on the recipient.
[11:54.540 --> 11:57.840]  Email tracking is also on by default, and you can toggle this on and off.
[11:57.840 --> 12:02.140]  This will simply include the 1x1 pixel image at the bottom of the email,
[12:02.140 --> 12:06.700]  where if it's rendered, you can deduce that your target has opened the email.
[12:12.560 --> 12:16.020]  The pages component is very similar to the email component,
[12:16.020 --> 12:20.180]  and this is where you store your HTML templates for your phishing webpages.
[12:20.840 --> 12:24.900]  I've got one template preloaded here in the Casterly Rock workspace,
[12:24.900 --> 12:29.540]  but the login templates we're going to be using with our email availability scenario
[12:29.540 --> 12:32.180]  are actually kept in the general workspace for now.
[12:32.180 --> 12:34.680]  So let's backtrack over there so we can edit them.
[12:36.080 --> 12:39.460]  And again, even though these two templates are only editable
[12:39.460 --> 12:44.240]  in the pages component of the general workspace,
[12:44.240 --> 12:48.940]  these will be available for selection with campaigns in any workspace.
[12:49.080 --> 12:51.980]  So we've got our username and password pages here.
[12:51.980 --> 12:55.680]  Let's pop these open just for a preview.
[12:56.780 --> 13:01.040]  And this is actually one of the best features about Reddler,
[13:01.040 --> 13:05.840]  is that you have the ability to chain up to four of your templated webpages together
[13:05.840 --> 13:07.660]  during any one campaign.
[13:07.660 --> 13:10.280]  So this can help you create a dynamic scenario
[13:10.280 --> 13:16.780]  or accurately mimic the user experience for your particular targeted site.
[13:17.800 --> 13:20.480]  Let's go in and edit one of these now.
[13:20.620 --> 13:24.080]  So we can see this is the same HTML editor that the emails component has.
[13:24.080 --> 13:26.300]  We've got the same iframe preview.
[13:26.300 --> 13:28.880]  We've also got the ability to clone a site.
[13:28.880 --> 13:37.960]  And we also can specify the trailing URL path that this specific webpage is going to be hosted on.
[13:38.120 --> 13:41.560]  Again, we've also got several variables that can be used.
[13:41.580 --> 13:46.240]  So the next URL variable is the variable you're going to be using the most.
[13:46.240 --> 13:50.040]  And this is how you tie your templated webpages together.
[13:50.040 --> 13:54.180]  So down in our form here on the username page,
[13:54.180 --> 13:58.300]  we can see the action attribute is just set to the next URL variable.
[13:58.300 --> 14:01.120]  This will get dynamically replaced at runtime
[14:01.120 --> 14:09.160]  with the trailing URL path of your second page in the sequence.
[14:09.160 --> 14:10.940]  So that will be replaced with this value here
[14:10.940 --> 14:15.020]  and bring users over to the password page when they submit their username.
[14:17.320 --> 14:25.320]  The payload URL variable is the same as the payload URL variable available in the emails.
[14:25.320 --> 14:28.800]  And again, this will let you use a button or a hyperlink
[14:28.800 --> 14:33.640]  to directly download the specified payload configured with your campaign.
[14:34.180 --> 14:38.700]  The serve payload variable is a little bit different from the payload URL variable
[14:38.700 --> 14:44.620]  in that you can just include this anywhere in your HTML template.
[14:44.620 --> 14:52.560]  And it will get replaced at runtime with a HTML meta tag, kind of like down here.
[14:52.560 --> 14:56.920]  And when someone browses to your page,
[14:57.100 --> 15:02.500]  it should automatically drop your specified payload to their file system
[15:02.500 --> 15:06.680]  without any type of button or hyperlink click.
[15:07.200 --> 15:11.960]  And for both of these, when using either of these,
[15:11.960 --> 15:14.580]  the tracking integrity is maintained.
[15:14.580 --> 15:18.780]  So the specific user ID of whoever is browsing your site at that moment
[15:18.780 --> 15:22.680]  will be inserted here in the payload URL so you can continue to track
[15:22.680 --> 15:25.320]  who exactly is downloading your payloads.
[15:26.260 --> 15:32.200]  The final three variables down here, login.fmt, username, and email,
[15:32.200 --> 15:37.740]  are there to help you mimic user experiences and do sort of a variable pass-through.
[15:37.740 --> 15:41.800]  If we check our password page here,
[15:41.800 --> 15:47.880]  we can see we've got the login.fmt value specified above our enter password header.
[15:47.880 --> 15:55.200]  And this will let us grab the value of an input box with the login.fmt name
[15:55.200 --> 15:58.940]  from the previous page's form submission and display it here.
[15:59.040 --> 16:03.820]  If we look back at our username page,
[16:03.820 --> 16:10.720]  the input box we're going to be entering data into has the name attribute set to login.fmt.
[16:10.820 --> 16:15.560]  Whatever data the user submits on this page here will be displayed on the second page
[16:15.560 --> 16:18.220]  to help mimic common login experiences.
[16:23.060 --> 16:28.080]  So we're halfway through the campaign makeup at this point, taking a look at emails and pages.
[16:28.080 --> 16:31.400]  All we've got left is target lists and profiles before we're ready to send.
[16:31.400 --> 16:36.100]  We'll go back to our Caskly Rock workspace at this point and get our target list prepped.
[16:36.340 --> 16:40.400]  We'll make a new list, and you can either add users one by one here
[16:40.400 --> 16:44.240]  by adding their information in this line and clicking the plus button,
[16:44.240 --> 16:48.540]  or you can upload a CSV file. So I'm just going to do that to save some time.
[16:48.540 --> 16:50.900]  We'll call the list Lannisters.
[16:53.200 --> 16:56.780]  And you can see this was filled out already with first name, last name, and email.
[16:56.780 --> 17:00.760]  Email is the only required value. First and last name are available though
[17:00.760 --> 17:06.020]  if you want to be able to reference the fname and lname type variables in your email template.
[17:06.320 --> 17:11.300]  We'll go ahead and create this, and this is going to be who we're sending to when we kick off our campaign.
[17:12.880 --> 17:16.100]  Profiles are our last required component to start a campaign.
[17:16.100 --> 17:21.600]  Similar to when we took a look at Pages, the profile we want to use is being housed in the General workspace.
[17:21.920 --> 17:24.940]  Instead of navigating back to the General workspace and looking at it there,
[17:24.940 --> 17:28.840]  I'm actually going to import it over to our current Caskly Rock workspace.
[17:34.660 --> 17:37.480]  So now our profile has been imported to our current workspace.
[17:37.480 --> 17:39.360]  We can take a look at it and make some edits.
[17:42.360 --> 17:46.700]  We can also change how it looks like when a user receives it.
[17:49.440 --> 17:54.000]  Down here you can see we've got the SMTP host, port, username, and password.
[17:54.000 --> 17:57.060]  We're also specifying we're going to be using a DLS connection.
[17:57.400 --> 18:01.760]  Save this in the test email to make sure that our profile is working.
[18:13.820 --> 18:16.800]  Great, so now that our profile is successfully working,
[18:16.800 --> 18:18.820]  we're ready to go generate a new campaign.
[18:21.680 --> 18:26.160]  The Campaigns component shows us our three previously run campaigns.
[18:26.160 --> 18:29.260]  All of these are completed, so none of them are active anymore.
[18:29.260 --> 18:31.460]  We'll go ahead and create a new campaign up here.
[18:31.840 --> 18:35.160]  The first set of options we're presented with are our hosting options.
[18:35.160 --> 18:39.440]  We'll select our domain that is going to host our phishing site, westerosport.com.
[18:39.440 --> 18:41.820]  We can see the IP that that domain resolves to.
[18:42.000 --> 18:48.280]  We'll also select our server, which is going to be worker1, also the IP address that our domain resolves to.
[18:48.280 --> 18:52.180]  If we try and select another worker that has a different IP address and continue,
[18:52.180 --> 18:54.580]  we will be forbidden from doing so.
[18:54.580 --> 18:56.600]  We'll go ahead and select worker1.
[18:56.780 --> 19:03.620]  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.
[19:03.700 --> 19:07.660]  This will reference the cert path supplied on the domains and servers page
[19:07.660 --> 19:09.420]  for the chosen domain.
[19:13.020 --> 19:18.400]  Moving on to our scenario options, we'll go ahead and specify a campaign name.
[19:23.610 --> 19:25.850]  And select our email template.
[19:25.850 --> 19:27.510]  We'll do our cloud email update.
[19:27.510 --> 19:32.110]  Optionally, you can also attach a file here. I'm not going to do so for this scenario, but it's there.
[19:32.610 --> 19:35.710]  This is what I was mentioning earlier when I said that you can
[19:35.710 --> 19:39.690]  choose to specify up to four pages per campaign
[19:39.690 --> 19:44.170]  to be used in sequence. We'll go ahead here and select our username page.
[19:44.430 --> 19:46.990]  And then sequentially our password page, so that once
[19:47.380 --> 19:50.610]  the user has submitted a username, they are presented with our password page.
[19:50.710 --> 19:54.110]  You can take this a step further and show a success page or something like that.
[19:54.110 --> 19:58.150]  I've never used all four pages here, but the option is there if you have
[19:58.370 --> 20:01.250]  a complicated scenario that requires something like that.
[20:02.550 --> 20:06.250]  Optionally, we can also specify a redirect URL. So after our last form
[20:06.250 --> 20:10.270]  is submitted, we can take them to the actual login page that we've cloned.
[20:10.270 --> 20:14.670]  I'll just go ahead and specify here, schneiderdowns.com.
[20:20.340 --> 20:22.680]  And also optionally, we can select some payload config.
[20:22.680 --> 20:26.740]  So we can pick a payload file that we've uploaded to Worker 1 previously.
[20:26.740 --> 20:31.180]  Also specify the trailing URL path that that payload will be hosted on.
[20:31.180 --> 20:34.840]  I'm not going to do that here. We'll run through another scenario in which we do configure
[20:34.840 --> 20:38.740]  these, but this is what the payload URL variable that you can use
[20:38.740 --> 20:42.780]  in your email templates and your page templates is going to link to eventually.
[20:45.980 --> 20:48.060]  And last, we have our sending options.
[20:48.380 --> 20:52.280]  We'll pick our list that contains our target email addresses, Lannisters.
[20:52.640 --> 20:56.220]  We'll pick our sending profile, so we'll go with the PyCell profile
[20:56.220 --> 21:00.460]  that will be imported into the Casterly Rock workspace. And optionally, we can also specify
[21:00.460 --> 21:04.040]  some batch sending. We can send two emails
[21:04.040 --> 21:08.240]  through at a rate of... on an interval of every 60 minutes
[21:08.240 --> 21:12.280]  here, if we don't want to blast our target with all emails at once. If we leave these configs
[21:12.280 --> 21:16.180]  blank, all emails will just be sent at one time. Also
[21:16.180 --> 21:20.260]  optionally, we can choose to start the campaign in the future. I'm not going to do
[21:20.260 --> 21:24.280]  that here. If you leave this blank, it'll start right now. And with that
[21:24.280 --> 21:27.220]  we'll go ahead and launch our campaign.
[21:29.320 --> 21:32.260]  So we'll give it a couple seconds here. We can see our campaign has been added to the
[21:32.260 --> 21:35.800]  campaigns page. And we'll give it a moment
[21:35.800 --> 21:40.260]  and when we click refresh, we should see that this campaign status changes
[21:40.260 --> 21:44.360]  to active. Okay, there we go. We can see we've also got an option
[21:44.360 --> 21:46.140]  now to kill a campaign and end it.
[21:48.000 --> 21:52.220]  We'll head over to the results component again and just filter down to our
[21:52.220 --> 21:56.340]  newly run campaigns. We can see all four emails have been sent. All four
[21:56.340 --> 22:00.160]  are currently unopened. We'll browse out to one of the inboxes here
[22:00.160 --> 22:03.280]  and log in. Let's simulate someone getting phished.
[22:11.410 --> 22:15.250]  We'll log into Searcy here and we can see we've got
[22:15.250 --> 22:19.890]  an email from MasterPycel. We trust everything from MasterPycel.
[22:19.890 --> 22:23.210]  We'll go ahead and we'll download the external images. We'll click the link
[22:23.870 --> 22:27.430]  and we're presented with our sign-in page here. So we can see we're at
[22:27.430 --> 22:31.710]  westerosupport.com with the trailing URL path we provided and also
[22:31.710 --> 22:34.830]  Searcy's unique ID. We'll go ahead
[22:35.830 --> 22:42.450]  provide our email address. We can see
[22:42.450 --> 22:46.490]  our variable passed through here to the second page. We'll go ahead and enter
[22:46.490 --> 22:56.040]  our password in. And we're hit with our redirect.
[22:57.580 --> 22:59.540]  So let's go back over to
[22:59.540 --> 23:03.660]  the UI here and we can see the statistics
[23:03.660 --> 23:07.020]  are actually already updated. We've got a little information on Searcy.
[23:07.780 --> 23:11.620]  So we can see the time stamps of everything, all the actions she took
[23:11.620 --> 23:16.020]  here, as well as the IP address that's all coming from the user agent.
[23:16.520 --> 23:19.800]  And if we come down here, we can
[23:19.800 --> 23:22.160]  see the username and password submitted.
[23:28.340 --> 23:33.020]  So while our cred harvesting campaign is running, I've got a couple more templates rigged up
[23:33.020 --> 23:36.880]  to do payload phish that should automatically drop a file to the
[23:36.880 --> 23:40.940]  user's file system when they browse out to the page. Let's go ahead and configure that
[23:40.940 --> 23:45.600]  to run real quick. Use brawlsuggestics.com
[23:45.600 --> 23:48.700]  We'll run that off of Red Alert Worker number 2.
[23:48.920 --> 23:51.160]  Again, we'll use 443 and SSL.
[24:01.190 --> 24:05.850]  Go ahead and name our campaign. Select our email. And again, I'm not going to
[24:05.850 --> 24:09.590]  attach the payload directly to the email. I'm going to
[24:09.590 --> 24:13.970]  specify it down here in the optional payload settings.
[24:27.820 --> 24:30.700]  And we'll send it out to the Lannisters. We'll use our
[24:30.700 --> 24:34.860]  Braavos Logistics profile and we'll just leave all this blank to send all the emails out at
[24:34.860 --> 24:41.140]  once. We'll give it a couple seconds here and we should
[24:41.140 --> 24:45.300]  see the campaign flip to active on our DefCon Worker 2.
[24:47.640 --> 24:48.980]  There we go.
[24:49.140 --> 24:53.980]  Come back over here. Filter down our results to just this campaign.
[24:53.980 --> 24:56.060]  We've got one email left to send.
[24:56.880 --> 24:59.680]  All emails have been sent out. Come back to
[24:59.680 --> 25:04.080]  Cersei's inbox. Check her email. She's got an invoice here from Braavos
[25:04.080 --> 25:07.280]  Logistics. Download the external images.
[25:08.460 --> 25:12.440]  So, building department is waiting to process the order before it can be shipped to Casterly Rock.
[25:12.440 --> 25:15.460]  We'll go ahead and download our invoice so we can fill it out.
[25:16.100 --> 25:20.160]  Come out to the page here and our invoice will automatically download.
[25:21.880 --> 25:23.560]  We'll head back to Red Alert.
[25:23.560 --> 25:27.700]  Refresh our stats. We can see we've got the download track on
[25:27.700 --> 25:31.600]  Cersei. And we can see all the information on where that's
[25:31.600 --> 25:38.630]  coming from. With our campaigns having run
[25:38.630 --> 25:43.190]  their course, we can come in here. We'll go ahead and kill both of these campaigns.
[25:43.190 --> 25:47.070]  Take them down. The page should no longer refresh.
[25:48.750 --> 25:50.410]  And if we come back to our domains and
[25:50.410 --> 25:54.450]  service page, we check Worker 1 and Worker 2. We should see that no
[25:54.450 --> 25:57.370]  campaigns are running on ports 443.
[26:05.260 --> 26:08.960]  That wraps up our demo. I'll flip back to the PowerPoint
[26:08.960 --> 26:13.220]  briefly here just to cover a couple potential to-dos.
[26:13.220 --> 26:17.360]  A couple things we're thinking about adding into Red Alert would be the ability to relay
[26:17.360 --> 26:21.480]  emails through a specified Red Alert worker. But the way things are currently set
[26:21.480 --> 26:25.480]  up, your Red Alert console is always going to be
[26:25.480 --> 26:29.080]  the IP address reaching out to the specified
[26:29.080 --> 26:33.180]  SMTP server in your profile configs and sending emails
[26:33.180 --> 26:37.080]  that way. So if something were to happen to the reputation of your console's
[26:37.080 --> 26:41.120]  IP address, it could potentially affect its ability to send emails.
[26:41.240 --> 26:45.240]  Adding in the ability to specify a worker to send the emails for your console
[26:45.240 --> 26:48.460]  would add a little bit more redundancy and
[26:48.900 --> 26:51.760]  work for that burnability of the workers.
[26:52.940 --> 26:57.200]  Another thing would be to potentially add in a mechanism
[26:57.200 --> 27:00.960]  to direct users to different webpages
[27:00.960 --> 27:04.560]  or scenarios based on the visiting user agent. So say you're potentially running
[27:05.260 --> 27:08.940]  a payload phishing campaign and a user
[27:08.940 --> 27:12.500]  visits your site from a mobile device.
[27:12.820 --> 27:16.560]  Detecting that via the user agent and then potentially redirecting
[27:16.560 --> 27:20.600]  these mobile users to a credential phishing attack
[27:20.600 --> 27:23.680]  would be something that we'd like to add in in the future.
[27:24.520 --> 27:27.580]  Also the ability to specify IPs associated with
[27:27.580 --> 27:31.980]  products such as Microsoft, ATP,
[27:31.980 --> 27:35.820]  Proofpoint, Mimecast, anything that may be going out and probing some of your phishing sites
[27:35.820 --> 27:39.740]  to determine if it's got malicious files being served or if
[27:39.740 --> 27:43.340]  it's got credential harvesting forms, anything like that.
[27:43.340 --> 27:47.740]  Putting specified IPs or ranges in and then redirecting these
[27:47.740 --> 27:51.680]  IPs to harmless sites. Kind of along that line
[27:51.680 --> 27:55.540]  also would be delaying the weaponization of your hosted payload.
[27:55.540 --> 27:59.800]  So when you go in and you select the payload you want to host off your worker and the trailing URL path
[27:59.800 --> 28:03.720]  potentially replacing that with a dummy payload that could serve for the
[28:03.720 --> 28:07.540]  first 45 seconds or 5 minutes after runtime.
[28:07.540 --> 28:11.620]  And then after that time has passed, anybody browsing to it
[28:11.620 --> 28:15.520]  and any hits for that link will actually drop your real
[28:16.140 --> 28:19.800]  malicious payload. And lastly would be the
[28:19.800 --> 28:23.980]  bypass that's out there for Office 365 Safe Links. Using relative
[28:23.980 --> 28:27.520]  URL paths and the HTML base tag to specify your
[28:28.240 --> 28:32.460]  domain instead of using absolute URLs all over your email.
[28:32.620 --> 28:36.460]  I'm not sure if this still works. I know this was a thing quite a while ago.
[28:36.580 --> 28:39.320]  Something that would be real easy to add into Redler.
[28:41.280 --> 28:44.020]  And that's the end of the presentation. I've got contact
[28:44.020 --> 28:47.680]  info there. As of the time I'm recording this, the GitHub
[28:47.680 --> 28:52.260]  repositories are not public yet. They will be in the very near future.
[28:52.320 --> 28:55.760]  And this is something that we're definitely open to community support
[28:55.760 --> 28:59.680]  on as well once this is public. So thanks everybody
[28:59.680 --> 29:01.820]  for watching and good luck phishing.