 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 Carillo 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 Redler? 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 in creating our own, which became Redler 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 web pages together in a way that mimics the user experience on popular cloud email services where usernames and passwords are submitted on sequential web pages. 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 events of wanting 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 for evolving 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 Cobaltrike 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, open 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 back end 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 winterfish.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 same domain, but off port 5000. So again, these are running on the same server, just different ports. So we're going to log in. And we've got a bit of a Game of Thrones theme here. So we're going to 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 Servers side, you can see I have three Redler workers connected with my console. And ideally, you could 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 a worker to console and console 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 paylids to be served. And 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, that the port's taken up. We'd want to fish off of something like 80. But you can actually be running campaigns in parallel off these workers. You could 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. This 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, it 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, form data, the API key is sent from the worker to the console. And again, if the API key does not match, when either end, the communications will fail. On the domain side, we can see the two domains I've bought configured for the purposes of the demo. Domains are only usable if the domain resolves to one of the IP addresses of your Redler 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 cert system has successfully generated. And we can see that the certain key paths have been updated with the default paths of Let's Encrypt certs. So 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 to the interface here. Next, we'll briefly cover the users and roles component. This page is only accessible to users who have been assigned a administrator type role. And from here, you can add and delete users, reset passwords, and also change what roles users are assigned to. On the users table here, we can see the admin user and JSnow user have been assigned the Reddler admin role. And the S.Tarly 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 Reddler admin role here, which is an administrator role, it has the ability to view all of 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. And 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 are 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 downloaded 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 an iframe here. You can see we're working with a template that is dealing with email availability issues. Some security changes have been made. Just gotta go log in and make sure that access has not been affected. And we're impersonating maester Pycel here, our maester of network communications. You can see there's a couple of variables in here. So we've got the first name 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, first name, last name, full name, email, and ID are just going to be unique variables based on the recipient. Email tracking is also on by default. You can toggle this on and off. This will simply include the one by one 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 web pages. 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, and 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 web pages together during any one campaign. So this can help you create a dynamic scenario or accurately mimic the user experience for your particular target and 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. Got the same iframe preview. They also got the ability to clone a site. And we also can specify the trailing URL path that this specific web page 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 gonna be using the most. And this is how you tie your template of web pages 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. I'll 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's 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. So 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 pages form submission and display it here. If we look back at our username page, the input box we're gonna be entering data into has the name attributes set to login FMT. So 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 list and profiles before we're ready to send. Go back to our Casterly 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 gonna do that to save some time, call the list, the 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 wanna be able to reference the F name and L name type variables in your email template. We're gonna create this and this is gonna 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, profile we wanna use this 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 Casterly Rock workspace. So now our profile's been imported to our current workspace. We can take a look at it and it makes that it's also changed how it looks like when the user receives it. And down here you can see we've got the SMTP host port username and password and we're also specifying where you're gonna be in the TLS connection. Save this and the test email to make sure that our profile's working. Great, so now that our profile is successfully working, we're ready to go generate a new campaign. So the campaigns component show us our three previously run campaigns. All of these are completed so none of them are active anymore. Go ahead and create a new campaign up here and the first set of options we're presented with are our hosting options. So we'll select our domain that is going to host our phishing site, lesterisport.com. We can see the IP that that domain resolves to. And we'll also select our server which is gonna be worker one. 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 worker one. We can also specify the port that we wanna host the campaign off of as well as whether or not we want to use SSL. And 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. And optionally you can also attach a file here. I'm not going to do so for this scenario but it's there. This was 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. So 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're presented with our password page. You could 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 one previously and also specify the trailing URL path that that payload will be hosted on. I'm not going to do that here. Well, 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. So we'll pick our list that contains our target email addresses, lanisters. We'll pick our sending profile. So we'll go with the PyCell profile we imported into the Casterly Rock workspace. And optionally we can also specify some batch sending. We could send two emails through at a rate of or 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 will go ahead and launch our campaign. So we'll give it a couple seconds here. We can see our campaign's 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 login and simulate someone getting fished. The login is sursy here. And we can see we've got an email for MasterPySell. We trust everything for MasterPySell. We'll go ahead and we'll download the external images. We'll click the link represented with our sign in page here. So we can see we're at westerosupport.com with the trailing URL path that we provided and also sursy's unique ID. We'll go ahead, wide our email address. We can see our variable pass 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. Got a little information on sursy. So we can see the timestamps of everything she's all the actions she took here as well as the IP address that's all coming from 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 fish 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 bravaslogistics.com. We'll run that off of Redler worker number two. Again, we'll use 443 in 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 gonna specify it down here in the optional payload settings. Then we'll send it out to the Lannisters. We'll use our bravas 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 two. There we go. Come back over here. Filter down our results to just this campaign. It's about one email left to send. All emails have been sent out. Come back to your services inbox, check your email. You just got an invoice here from bravaslogistics. Download the external images. So building departments 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 automatically downloads. We'll head back to Redler, 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, page no longer refresh. And if we come back to our domain and service page, we check worker one and worker two. 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. So a couple things we're thinking about adding into Redler would be the ability to relay emails through a specified Redler worker. But the way things are currently set up, your Redler 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. 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, but add a little bit more redundancy and work for that burn ability of the workers. Another thing would be to potentially add in a mechanism to direct users to different web pages or scenarios based on the visiting user agent. So say you're potentially running a payload fishing 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 fishing attack would be something that we'd like to add 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 fishing sites to determine if it's got malicious files being served or if it's got credential harvesting forms, anything like that. Putting a 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 five 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, the HTML base text specify your domain instead of using absolute URLs all over your email. I'm not sure if this still works. I know this was the thing quite a while ago, something that would be real easy to add into Redler. And that's the end of the presentation. Got to 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 fishing.