WEBVTT 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:14.100 A little bit about me. 00:14.120 --> 00:18.360 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:31.600 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. 00:32.060 --> 00:38.900 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. 00:39.580 --> 00:47.420 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. 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 --> 00:57.420 So why Reddler? 00:57.600 --> 01:05.380 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. 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:24.020 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. 01:24.240 --> 01:36.860 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. 01:37.080 --> 01:39.840 We think this is a must for phishing in today's environment. 01:40.820 --> 01:48.440 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. 01:48.440 --> 01:55.320 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. 01:55.320 --> 02:03.720 We wanted all data stored somewhere centralized that could manage other phishing servers and perform remote actions for us, such as generating SSL certificates. 02:05.280 --> 02:14.280 Encryption of sensitive data was also important, mostly revolving around phishing data, such as user submitted form data and SMTP credentials. 02:15.260 --> 02:27.320 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. 02:27.960 --> 02:40.300 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. 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:59.340 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. 03:00.040 --> 03:07.640 The client is a web interface written in Angular 7 that allows you to interact 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:27.740 The workers are what actually runs your phishing web servers and sends statistics and form data back to the console. 03:28.140 --> 03:34.420 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. 03:36.360 --> 03:39.040 Now let's transition over to the demo. 03:39.560 --> 03:47.440 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. 03:47.900 --> 03:57.180 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. 03:57.180 --> 04:00.300 So again, these are running on the same server, just different ports. 04:00.300 --> 04:01.740 So go ahead and log in. 04:01.740 --> 04:05.720 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:11.320 We'll come back to this page in a minute. 04:11.320 --> 04:15.300 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:51.660 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. 05:51.660 --> 06:01.820 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. 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:33.040 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. 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:33.320 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. 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:16.780 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. 08:18.780 --> 08:22.240 Right now, there's only two role types. 08:22.240 --> 08:25.000 There's the administrator types and the user types. 08:25.100 --> 08:38.580 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. 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:07.280 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. 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:17.810 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. 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:07.960 You can see we're working with a template that is dealing with email availability issues, 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:43.140 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. 11:43.260 --> 11:52.360 And the rest of the variables here, firstName, lastName, fullName, email, and ID, 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:06.700 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. 12:12.560 --> 12:20.180 The pages component is very similar to the email component, and this is where you store your HTML templates for your phishing webpages. 12:20.840 --> 12:32.180 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. 12:32.180 --> 12:34.680 So let's backtrack over there so we can edit them. 12:36.080 --> 12:48.940 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. 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:07.660 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. 13:07.660 --> 13:16.780 So this can help you create a dynamic scenario 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:58.300 So down in our form here on the username page, we can see the action attribute is just set to the next URL variable. 13:58.300 --> 14:09.160 This will get dynamically replaced at runtime with the trailing URL path of your second page in the sequence. 14:09.160 --> 14:15.020 So that will be replaced with this value here 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:33.640 And again, this will let you use a button or a hyperlink to directly download the specified payload configured with your campaign. 14:34.180 --> 14:44.620 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. 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 --> 15:06.680 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. 15:07.200 --> 15:14.580 And for both of these, when using either of these, the tracking integrity is maintained. 15:14.580 --> 15:25.320 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. 15:26.260 --> 15:37.740 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. 15:37.740 --> 15:47.880 If we check our password page here, we can see we've got the login.fmt value specified above our enter password header. 15:47.880 --> 15:58.940 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. 15:59.040 --> 16:10.720 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. 16:10.820 --> 16:18.220 Whatever data the user submits on this page here will be displayed on the second page 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:46.180 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. 16:46.180 --> 16:48.540 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 --> 16:58.780 Email is the only required value. 16:58.900 --> 17:06.020 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. 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:28.840 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. 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:18.820 Great, so now that our profile is successfully working, 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:54.580 If we try and select another worker that has a different IP address and continue, 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:09.420 This will reference the cert path supplied on the domains and servers page 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:29.530 Optionally, you can also attach a file here. 19:29.530 --> 19:32.110 I'm not going to do so for this scenario, but it's there. 19:32.610 --> 19:41.230 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. 19:41.470 --> 19:44.170 We'll go ahead here and select our username page. 19:44.430 --> 19:50.610 And then sequentially our password page, so that once 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 --> 20:01.250 I've never used all four pages here, but the option is there if you have a complicated scenario that requires something like that. 20:02.550 --> 20:05.010 Optionally, we can also specify a redirect URL. 20:05.090 --> 20:10.270 So after our last form 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:32.520 I'm not going to do that here. 20:32.520 --> 20:42.780 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. 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:58.640 We'll pick our sending profile, so we'll go with the PyCell profile that will be imported into the Casterly Rock workspace. 20:59.120 --> 21:02.160 And optionally, we can also specify some batch sending. 21:02.160 --> 21:11.240 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. 21:11.240 --> 21:15.860 If we leave these configs blank, all emails will just be sent at one time. 21:15.900 --> 21:19.060 Also optionally, we can choose to start the campaign in the future. 21:19.300 --> 21:21.220 I'm not going to do that here. 21:21.300 --> 21:23.540 If you leave this blank, it'll start right now. 21:23.540 --> 21:27.220 And with that we'll go ahead and launch our campaign. 21:29.320 --> 21:30.880 So we'll give it a couple seconds here. 21:30.880 --> 21:33.520 We can see our campaign has been added to the campaigns page. 21:34.180 --> 21:41.240 And we'll give it a moment and when we click refresh, we should see that this campaign status changes to active. 21:42.460 --> 21:43.120 Okay, there we go. 21:43.120 --> 21:46.140 We can see we've also got an option now to kill a campaign and end it. 21:48.000 --> 21:53.380 We'll head over to the results component again and just filter down to our newly run campaigns. 21:53.380 --> 21:56.020 We can see all four emails have been sent. 21:56.020 --> 21:57.680 All four are currently unopened. 21:57.920 --> 22:01.300 We'll browse out to one of the inboxes here and log in. 22:01.380 --> 22:03.280 Let's simulate someone getting phished. 22:11.410 --> 22:17.010 We'll log into Searcy here and we can see we've got an email from MasterPycel. 22:17.850 --> 22:19.890 We trust everything from MasterPycel. 22:19.890 --> 22:22.190 We'll go ahead and we'll download the external images. 22:22.410 --> 22:26.390 We'll click the link and we're presented with our sign-in page here. 22:26.410 --> 22:33.370 So we can see we're at westerosupport.com with the trailing URL path we provided and also Searcy's unique ID. 22:33.810 --> 22:37.710 We'll go ahead provide our email address. 22:41.610 --> 22:45.550 We can see our variable passed through here to the second page. 22:45.550 --> 22:47.810 We'll go ahead and enter our password in. 22:54.100 --> 22:56.040 And we're hit with our redirect. 22:57.580 --> 23:04.960 So let's go back over to the UI here and we can see the statistics are actually already updated. 23:04.960 --> 23:07.020 We've got a little information on Searcy. 23:07.780 --> 23:16.020 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. 23:16.520 --> 23:22.160 And if we come down here, we can see the username and password submitted. 23:28.340 --> 23:39.640 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. 23:39.820 --> 23:42.480 Let's go ahead and configure that to run real quick. 23:43.640 --> 23:48.700 Use brawlsuggestics.com 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:02.830 Go ahead and name our campaign. 24:02.830 --> 24:04.550 Select our email. 24:05.010 --> 24:09.310 And again, I'm not going to attach the payload directly to the email. 24:09.310 --> 24:13.970 I'm going to specify it down here in the optional payload settings. 24:27.820 --> 24:29.980 And we'll send it out to the Lannisters. 24:30.020 --> 24:35.660 We'll use our Braavos Logistics profile and we'll just leave all this blank to send all the emails out at once. 24:39.060 --> 24:45.300 We'll give it a couple seconds here and we should see the campaign flip to active on our DefCon Worker 2. 24:47.640 --> 24:48.980 There we go. 24:49.140 --> 24:50.760 Come back over here. 24:51.140 --> 24:53.980 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:58.720 All emails have been sent out. 24:58.920 --> 25:00.800 Come back to Cersei's inbox. 25:00.800 --> 25:01.880 Check her email. 25:02.280 --> 25:05.140 She's got an invoice here from Braavos Logistics. 25:05.340 --> 25:07.280 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:25.420 Refresh our stats. 25:25.420 --> 25:28.520 We can see we've got the download track on Cersei. 25:29.560 --> 25:32.660 And we can see all the information on where that's coming from. 25:36.750 --> 25:40.990 With our campaigns having run their course, we can come in here. 25:40.990 --> 25:43.190 We'll go ahead and kill both of these campaigns. 25:43.190 --> 25:44.370 Take them down. 25:45.050 --> 25:47.070 The page should no longer refresh. 25:48.750 --> 25:53.310 And if we come back to our domains and service page, we check Worker 1 and Worker 2. 25:53.310 --> 25:57.370 We should see that no campaigns are running on ports 443. 26:05.260 --> 26:07.540 That wraps up our demo. 26:07.540 --> 26:13.220 I'll flip back to the PowerPoint briefly here just to cover a couple potential to-dos. 26:13.220 --> 26:20.120 A couple things we're thinking about adding into Red Alert would be the ability to relay emails through a specified Red Alert worker. 26:20.120 --> 26:34.060 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. 26:34.060 --> 26:41.120 So if something were to happen to the reputation of your console's IP address, it could potentially affect its ability to send emails. 26:41.240 --> 26:51.760 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. 26:52.940 --> 27:03.220 Another thing would be to potentially add in a mechanism to direct users to different webpages or scenarios based on the visiting user agent. 27:03.220 --> 27:12.500 So say you're potentially running a payload phishing campaign and a user visits your site from a mobile device. 27:12.820 --> 27:23.680 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. 27:24.520 --> 27:42.620 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, 27:42.620 --> 27:43.340 anything like that. 27:43.340 --> 27:49.580 Putting specified IPs or ranges in and then redirecting these IPs to harmless sites. 27:50.480 --> 27:55.540 Kind of along that line also would be delaying the weaponization of your hosted payload. 27:55.540 --> 28:07.540 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. 28:07.540 --> 28:17.760 And then after that time has passed, anybody browsing to it and any hits for that link will actually drop your real malicious payload. 28:18.200 --> 28:23.200 And lastly would be the bypass that's out there for Office 365 Safe Links. 28:23.260 --> 28:32.460 Using relative URL paths and the HTML base tag to specify your domain instead of using absolute URLs all over your email. 28:32.620 --> 28:34.180 I'm not sure if this still works. 28:34.180 --> 28:36.460 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:43.220 And that's the end of the presentation. 28:43.220 --> 28:45.040 I've got contact info there. 28:45.040 --> 28:50.020 As of the time I'm recording this, the GitHub repositories are not public yet. 28:50.020 --> 28:52.260 They will be in the very near future. 28:52.320 --> 28:58.780 And this is something that we're definitely open to community support on as well once this is public. 28:58.780 --> 29:01.820 So thanks everybody for watching and good luck phishing.