WEBVTT 00:05.670 --> 00:15.930 Hi, my name is Nevada and Cam and I created a tool called Squarefish that combines QR codes and OAuth 2.0 device code flow. 00:15.930 --> 00:29.310 We are going to go over some QR code and OAuth device code flow introductory material, touch on some previous research, and then demo both Squarefish and a Squarefish sub-tool called Refresh. 00:29.310 --> 00:31.270 Thank you for joining us. 00:37.830 --> 00:39.150 Who are we? 00:39.770 --> 00:44.430 Cam and I work at SecureWorks and do security research and red teaming. 00:44.430 --> 00:49.890 We wrote a tool called Fish in Suits last year and expanded on that research this year with Squarefish. 00:49.970 --> 00:58.010 I've been doing InfoSec stuff for over 15 years and have held a number of roles through that time with a love of all things offensive. 00:58.350 --> 01:03.190 The past six years have really been focused on offensive security and research. 01:03.710 --> 01:14.710 Cam has been in InfoSec for six years and has authored a large number of tools including O365 Spray, BridgeKeeper, Redirect.Rules, and WhiskeySaml. 01:20.850 --> 01:23.850 So, we're going to start with the basics. 01:23.970 --> 01:25.430 What is a QR code? 01:25.430 --> 01:29.510 I mean, at this point, pretty much everyone knows what a QR code is. 01:29.510 --> 01:34.710 It's a barcode of sorts that contains data, often in the form of a URL. 01:34.770 --> 01:39.870 You can even do some cool things with them, like the moving QR code you see on the screen. 01:40.670 --> 01:44.310 I think everyone can probably guess where that QR code leads you. 01:53.100 --> 02:00.340 Although QR codes have been around for a long time, their usage has really exploded in the last five to ten years. 02:00.380 --> 02:07.200 We see them everywhere, including restaurant menus, user manuals, MFA registration, and even on Super Bowl commercials. 02:07.200 --> 02:17.320 People have become accustomed to using QR codes in their everyday life, and as we saw during the Super Bowl, many will scan them without concern for their content. 02:22.730 --> 02:25.810 So, what is a QR code to an attacker? 02:25.810 --> 02:30.770 The most obvious is probably just redirecting users to malicious sites. 02:31.110 --> 02:42.730 It probably can also work to help bypass some spam and phishing filters, although it's worth noting that Microsoft appears to be checking URLs that are in QR codes in certain formats. 02:42.790 --> 02:45.090 We can talk a bit more about this later. 02:45.550 --> 02:56.030 Another cool way to use QR codes is to embed buzzing or injection type strings in them to test QR code reading software for the applications that consume the data from it. 03:02.220 --> 03:11.520 OAuth device code flow probably isn't as well known, or at least as well understood, as QR codes are, but most folks have probably used it at some point. 03:11.740 --> 03:16.780 The most familiar implementation of this would probably be TV streaming apps and devices. 03:16.940 --> 03:19.440 This is really a great use case for the flow. 03:19.440 --> 03:25.820 It prevents users from having to enter passwords into on-screen keyboards using only a remote control. 03:33.420 --> 03:38.460 Device code flow is also used by Microsoft as well as other cloud providers. 03:38.460 --> 03:44.820 Oftentimes, this involves a client application asking for authentication and OAuth grants. 03:50.870 --> 03:55.690 Here's an illustration of the OAuth device code flow. 03:55.690 --> 04:04.550 The client uses a client ID which identifies the application and a scope which identifies the requested permissions. 04:04.670 --> 04:11.390 The endpoint responds with the device code, user code, and verification URI. 04:11.390 --> 04:16.110 The user can then visit that URI and enter the user code. 04:16.110 --> 04:23.430 They will then be prompted to authenticate and grant the access requested as defined in the application scope. 04:23.850 --> 04:35.430 While this is happening, the original client is polling the back end, waiting for authentication to happen, basically getting a wait response until the user authenticates. 04:35.430 --> 04:38.730 This generally has about a 15-minute window. 04:39.010 --> 04:51.310 After the user authenticates, the response to the polling request will include an access token, a refresh token, if needed for the requested scope, and an ID token. 04:58.420 --> 05:06.900 Last year, when we first looked at the OAuth device code flow, we thought it would be useful as a phishing mechanism, so we wrote a tool called Phish and Suits. 05:12.720 --> 05:25.900 One of the things we were really excited about was that client IDs of verified apps could be found online, and as long as the public flow was enabled on them, you didn't need a client secret to use them for phishing. 05:25.900 --> 05:34.580 The prompt on the right shows the requested permissions when using a verified app with Phish and Suits and getting the verified app check mark. 05:34.840 --> 05:44.120 This was a huge improvement over prior OAuth phishing, which often required registering your own application and usually came with a big unverified warning. 05:44.380 --> 05:49.000 The other great part was that there was no malicious URL required. 05:49.580 --> 05:56.600 Straight from an email or text, a user visited the legitimate Microsoft site and entered the code. 06:04.000 --> 06:12.980 We weren't the only ones that noticed this behavior and how it might be useful for phishing, and other folks published the technique and similar tools as well. 06:13.140 --> 06:17.700 I encourage anyone who wants a deeper dive into the topic to check out their research. 06:24.030 --> 06:37.790 So we've covered some of the pros of OAuth device code phishing, like verified and first-party apps can be used, it adds a layer of obfuscation, and the user enters their credentials into the actual Microsoft site. 06:37.790 --> 06:39.850 But there is a pretty big con. 06:39.850 --> 06:48.270 There's only a 15-minute window from the time the initial code is sent via text or email to when the authentication has to happen. 06:48.550 --> 07:00.270 Since so much of our work is based on statistics and based around a small percentage of success, having our email expire before many users even have the chance to read it obviously creates a problem. 07:05.590 --> 07:08.190 Squarefish is a Python tool that we developed. 07:08.190 --> 07:16.790 It aims to combine QR codes with the OAuth device flow in order to decouple the device flow from the initial phishing email. 07:16.790 --> 07:23.770 This is to prevent the device code that was emailed from expiring prior to the user interacting with it. 07:26.680 --> 07:35.660 An attacker will send a target victim an email that will contain a QR code and information relating to a given pretext. 07:35.800 --> 07:45.020 For example, an attacker will send an email that will contain information regarding the target's Microsoft Authenticator token expiring. 07:45.020 --> 07:54.320 The email will then instruct the user to scan the provided QR code in order to generate a new Microsoft Authenticator token. 07:54.380 --> 08:02.780 The provided QR code will be embedded with a link that directs the target victim to an attacker-controlled Squarefish server. 08:06.920 --> 08:16.820 Once the victim scans the QR code that was provided in the initial phishing email, they will be directed to an attacker-controlled Squarefish server. 08:16.820 --> 08:20.560 The user's email will be passed along as a GET parameter. 08:20.680 --> 08:27.300 Once the victim request is received by the Squarefish server, several tasks occur in the background. 08:27.380 --> 08:36.400 First, the user's browser is redirected away from the Squarefish server to Microsoft's device code authentication webpage. 08:36.400 --> 08:38.300 This happens instantly. 08:38.380 --> 08:49.980 Second, Squarefish will use the victim's email provided via a GET parameter to initiate the OAuth device code flow and retrieve a new device code. 08:49.980 --> 08:57.900 Third, Squarefish will send a follow-up email to the victim containing the retrieved OAuth device code. 08:57.900 --> 09:12.840 The email will attempt to replicate the look and design of an authentic Microsoft OAuth device code email and will provide the direct link to the legitimate Microsoft device code authentication endpoint. 09:13.100 --> 09:23.220 Lastly, once the email has been sent, Squarefish will begin polling Microsoft for authentication until the device code expires. 09:28.400 --> 09:39.560 Once the victim receives the follow-up email from Squarefish that contains the device code, they will visit the legitimate Microsoft endpoint to authenticate the device code. 09:39.580 --> 09:48.900 Once the user enters the provided device code, they will be prompted with a permission request for the given application's client ID. 09:49.160 --> 10:01.080 Since we are able to leverage legitimate existing applications found on the web, we are able to prevent any sort of unverified application warnings displayed to the user. 10:01.100 --> 10:08.820 In many cases, we can leverage verified applications and the user will see a verification blue check mark. 10:12.520 --> 10:29.560 Once the user submits their credentials and authenticates the application via the device code flow, the polling done by Squarefish in the background will identify and pull down the authentication and refresh tokens for the associated user. 10:29.560 --> 10:33.560 The data is then saved locally as a JSON file. 10:33.800 --> 10:38.100 On the next slide, you will see a demo execution of Squarefish. 10:38.100 --> 10:43.360 The demo will include a user scanning the provided QR code off screen. 13:06.170 --> 13:09.690 Additional considerations when using Squarefish. 13:11.450 --> 13:13.310 What about MFA? 13:13.410 --> 13:20.030 So if MFA is required, the user will use it when they're prompted to authenticate. 13:20.030 --> 13:27.890 Although if they are already authenticated, they might not need to enter a password or use MFA at all, depending on their corporate policies. 13:30.140 --> 13:33.680 What about sending emails and the account used to send emails? 13:33.680 --> 13:37.760 Squarefish was built and tested using a Gmail account for sending emails. 13:38.100 --> 13:42.800 And for many reasons, this may not be the best option for actual engagements. 13:44.580 --> 13:49.520 It's also worth noting that the QR code does contain a malicious domain. 13:49.520 --> 13:53.820 This was something that we were able to avoid with our earlier tool Fish and Suits. 13:53.820 --> 13:56.240 There are a couple of things to note here. 13:56.460 --> 14:06.200 One, if malware analysis, either automated or human, checks the link, they will be redirected to the legitimate Microsoft device code site. 14:06.660 --> 14:10.520 So they may not identify it as a phishing site at all. 14:10.680 --> 14:17.720 Two, if anything hits that link, it will send the second email without user interaction. 14:17.860 --> 14:24.800 So you may want to wait to bring the server up a few minutes after you've sent the initial phishing email. 14:26.360 --> 14:33.580 Three, you will want to use all of your other malicious domain tricks to ensure the domain itself isn't flagged. 14:33.900 --> 14:44.960 And four, the big advantage here is that the malicious domain will be visited by the QR code reader on the user's phone, which probably won't be on the corporate network. 14:44.960 --> 14:50.540 And since they are using the QR code reader, it won't be open from the email application. 14:51.380 --> 14:56.500 Also, be sure you're utilizing all your other good phishing techniques and tactics. 14:56.660 --> 15:00.480 And there's some links on this slide for additional resources there. 15:06.180 --> 15:12.480 Now that we have a user's refresh token, we wanted to look into what exactly we could do with it. 15:12.660 --> 15:23.360 Research done by public researchers, as well as our own SecureWorks researchers, Ryan Cobb and Tony Gore, identified what is known as FOCI, or Family of Client IDs. 15:23.940 --> 15:42.940 According to the Family of Client IDs GitHub, undocumented functionality in Azure Active Directory allows a group of Microsoft OAuth client applications to obtain special family refresh tokens, which can be redeemed for bearer tokens as any other client in the family. 15:43.400 --> 15:51.380 What this means is we can effectively exchange our refresh token for a new refresh token associated to a different application. 15:51.580 --> 15:57.620 Along with requesting a new refresh token, we can also modify the scope of the token requested. 16:02.260 --> 16:16.680 With this process, we created a small tool called Refresh to provide an automated and easy method of obtaining a refresh token for a different application and leveraging that access to search and extract data. 16:16.880 --> 16:28.980 Refresh will take in the outputted authentication JSON file from Squarefish and will exchange the refresh token for a token associated with the Microsoft Graph API. 16:29.160 --> 16:36.860 With this token, we are able to search emails, users, groups, organizations, OneDrive, and even SharePoint. 16:42.510 --> 16:56.030 Refresh will scrape and search the Microsoft Graph API using the newly exchanged token and will save all of the found data into user-associated JSON files for easy parsing. 16:56.030 --> 17:00.390 The next slide will show a demo execution of Refresh. 17:50.980 --> 17:53.480 That is it for our presentation. 17:53.480 --> 17:55.840 We really appreciate you taking the time to watch it. 17:55.840 --> 18:01.560 If you're interested in learning more about us or our tools, feel free to check out the links here. 18:01.620 --> 18:02.780 Thanks again.