BSides Berlin 2023: Jorge Gimenez - Phishing techniques for challenging environments

welcome [Applause] H uh okay so hello everyone so nice to see how vs is growing uh so thanks for everyone for organizing this and today I'm going to talk I'm jge and today I'm going to talk about performing fishing engagements in really challenging environments you were expecting my colleague Faby today um uh or he is the original author of This research with Danny but unfortunately things happening and he has covid and his most likely replacement is right now in New York in vacation so that end up with me basically a still in their research so yeah hopefully uh hopefully you like it uh also thanks a lot for to to Jacob uh and Matias for for their support it was

really much appre apprciated uh and yeah you also might know me because I was also here last year presenting about EDR evasion so I feel like we are ending a cycle here with uh with this initial initial access so now getting back to to a red team engagement you can see uh that uh there's three phases and today we are going to spefically focus on the initial compromise so how we get into an organization and how we land a footh hole to basically uh be within the organization environment and exploit new targets and this talk starts and and the idea of this talk is because as a red teamers we realize that fishing has become ex extremely harder and is

becoming harder each day last year I was here talking about something called malware fishing and it was because um I remember a few years back uh it was really easy to just go into organization and just Fe for credentials and just connect to his VPN with no further uh problem but because of how we are facing the environments right now we need to do stuff like malware fishing in malware fishing we create a a binary or a malicious uh malicious um executable that lands on the system and we try to maintain and persist over access but the problem here is that edrs are improving and basically edrs are everywhere so right now it's not so easy to also deliver malware into

a into a really um sophisticated organization if you want to know more you can see hores which is me talking in hacking the Box last year in Singapore or even like the one at bides and now today we are going to focus about something different which is credential fishing in credential fishing uh as I told you before it was really easy a few years back you just you just f for credentials and you have access to its VPN so you can uh conduct your action freely now it's not the case anymore because first MFA is basically deployed everywhere which means that you don't only need to fix for the credentials but Al also for the MFA code

which creates more complex attack kill chains and secondly uh this makes really hard to F to maintain your access because the MFA code is only valid once so you need to find a reliable way of keeping your access and enroll our new device today we are going to show you some examples of how us as a as a red teamer uh as a red teamers deal with MFA first let's have a look at how uh usually hackers approach uh fishing uh M fishing uh fishing in in environments with MFA the first Technique we are going to talk about is called reverse proing and it's basically the de facto uh standard for performing these kind of

attacks in this uh in this example I'm going to show you the graph and I hopefully uh I hopefully explain it correctly so you can understand but it can be a bit complex we are using a tool named a jings which is basically the easiest way of weaponize this kind of attacks and the flow is quite simple so first we as an attacker create a fake a fake website in attacker.com that mirrors the original site and we send a link to our Target and when Target opens the website it Sayes a replica of the of the website he usually uh used to log so it makes it makes sense right like I'm s link I just log in the site I

always login so secondly what we do is that in this website we created we proed all the requests to the original site so the authentication actually happens in the original site once the big team realizes that the website is legit and that everything we are doing is correct introduces both credentials and TFA code if that's the case and finally we ask up to the credentials and session cookies and then reuse them in further attacks of course the flow is just is as simple as it seems we set the server with the reverse proing all the request to our final Target and the user just enter his credentials and we get a session but of course as this was a

pretty simple technique uh companies have realized that maybe there's something we can do to prevent this of course um and a lot of companies are actually now implementing some kind of protection that prevent this from happening in the first place today we are going to talk about some JavaScript based fishing protections that we are now facing in some of the most important and and relevant sites we need to fish the JavaScript the JavaScript protection is actually quite simple it's JavaScript code that is executing on the client browser and that checks for example if the domain name is the same as it should be for example in this case you see that the JavaScript code checks

if the attacker.com domain is the company.com domain and as it sees that the domain domain name doesn't match it realizes that this is not um this is indeed a malicious action so it completely breaks the login flow it completely breaks the authentication and the authentication fails some of you might be thinking oh but that's Cent code then we can just modify it and that's correct but the problem here is that basically this code is minified it changed regularly and the third problem we face is that you need to invest a lot of time to to basically overcome this problem and in the end it's not worth it because in campaigns that take used to tend quite some time

we need to optimize our resources so we needed to find uh we needed to find a successful and sustainable way of conducting this kind of engagements against sites that are implementing this kind of protections and that's when uh we real we realize that we need to create something new we implemented our own fing setup and we solve the problem by using something called browser instrumentation again let's get back at at at a different graph and the first step is the same the user opens a website that in this case is not uh is not mirroring the original site by just recreating the original site we are just creating a fake website that mirrors the cont content of the original site the

big team opens the website and Sayes okay it's what I was expecting it's ask it's asking me to log in so the big team logs in and introduces its credentials and optionally is two is two Factor authentication code in case it exists but what we are doing now is a bit different once we grab those credentials we spound a new browser and uh basically we use this browser to authenticate against the real website that means that the JavaScript code is going to check for the domain and as the authentication is happening in a browser in the real website the authentication is going to be successful because in this case the JavaScript code that is checking the domain is going to

realize that domain is the name is the same one because the authentication is actually happening in the real website once it is successful we just grab the session the session and the cookies and we can perform our actions as you can see this flow is a bit different in the first example we were proing all the requests in in real time to the original website and here you can you can think it a bit differently you can think for example if I F someone I get his credentials and I can use them in a later point it doesn't even need to be automated I just f for them and then reuse them it's automated because

basically the tofa codes have a really short time uh lifespan so it needs to be quick but if you think about credentials this is like the simplest approach to do it because we are just first Gathering the credentials and then reusing them in a different browser as a user would do to use this is what we call browser instrumentations because the authentication flow is basically uh is B basically designed to be run automatically the browser just conducts the aution the actions automatically some other people also realize that this was a sustainable way of fighting this problem and that's the reason uh Kuba the the author of a jins which is the tool I said before

implemented its own um its own approach called a puppet which is part of ail thingss Pro but even if we have solved this problem and now we uh we can fight JavaScript uh JavaScript um uh JavaScript uh uh JavaScript protections we realize that there's new protections that we need to face and that there's no way we can we can do that with a with a fake domain that's when Pass Key ju key or other kind of authentications arrive and there's F2 and F2 prevents completely these kind of attacks I I'll explain you why so I'll try my best but I'm not an expert in this so uh I try to make it really simple what we did here

uh is that um in in in Fido 2 in in this Hardware in this Hardware uh MFA devices the the MFA is not a simple MFA code but but the MFA process is being signed with the original domain so for what what it's going to happen is that the when the user goes to the website and signs and uses his Hardware Key the MFA token is going to be signed for attacker.com and when we try the authentication in company.com it's going to fail because it's going to realize okay that's not the domain I was authenticating for but we can bypass it or that's what we realized in some scenarios um in a recent challenge basically we were

targeting an organization that was based on GitHub uh um and basically enforce the use of of Hardware Keys everywhere so that was quite a challenging environment for us because we never face something like that and we realize that even if you implement it if you don't implement it properly and consistently you can still bypass it uh we did this for GitHub and this was based on three problems the first problem GitHub forces you to have a legacy MFA Pro MFA MFA service that means you need to have a um top or SMS or anything of the F of the first things I explained to you in the in the first slides secondly GitHub allows you to

request uh through his API the gpg key the gpg key names for some of the users which means that the UB key uh information might be stored there and you can use that to build a fast full story uh in a fishing campaign and the third problem and one of the biggest is that you can view recovery codes up to 15 minutes after loging so once you log you can use that those recovery codes to add new MFA devices and basically complete a full account takeover you can log in whenever you want but now let's have a look again at the same graph as before and you'll see just a slight difference first the user

opens the website with a recreation of the original GitHub site but in this case what we are doing is that we are expl we are showcasing the two first problems I I I mentioned the first we are uh forcing the user to use its Legacy um its Legacy MFA implementation so top or SMS because it's mandatory by GitHub and secondly we are showcasing the UI key name of the user to tell tell him okay your U key is not working right now we don't support Howard authentication please use your legacy uh MFA implementation that we ask you to have the user is like okay if that's the case I just go to my phone and get the

top and then he introduces both credentials and top and as I told you before we just again a spa a new browser and relay this whole authentication to GitHub obtaining then a session and a cookie so the thing is basically is the same attack and this is basically uh this is basically possible because gith have enforces the use of Legacy protocols so even if we are forced to use Hardware MFA everywhere if we are still forced to use Legacy in any way you the attacker can still trick the user into using these Legacy protocols that doesn't prevent these kind of attacks also the third problem is I told you you can be recovery codes up to 15

minutes after login and there's no alert on this so uh it was quite stealthy for us we could just compromise the account of a really technical administrator of the organization so technical people also can be fed and secondly um we can just completely compromise the account by using his recovery code uh we informed GitHub thanks to this and uh thanks to you all now this is fixed and recovery code now trigger an alert whenever this happens and now uh there's a demo uh that my colleagues have prepared uh so thanks a lot for that uh now I don't know the setup so I think I go next and it starts playing you can see uh what basically I

explain says that the juub key is not working so you need to use your top your your legacy MFA implementation you can see first that uh the credential are going to be wrong to show you that it's actually

working here is when in the real browser we go to the Legacy uh implementation to Showcase that we can use

that and now we are logged in and the user gets redirected to a random website and I think that's all yeah so what we can get from here there's like three type of ways the first is that JavaScript code can be evaded by user browser instrumentation that's the first thing you can also modify the client code but as I told you it's really not sustainable second part you can completely defeat this uh domain based uh fing attempts by just using Hardware keys but third if you don't get rid of your uh fallback methods you still are going to face the same problem because attackers can force your user your users to downgrade to other protocols that are

not secure and that's all for today

thank you very much and also thank thanks to the colleagues that helped out with the last minute scheduled changes to make this happen um we have time for questions I think it's a fair game uh to uh if the colleagues want to help out with some questions answers to also help out do we have questions yes okay I'll try my

best thanks for ah thanks for the talk um do you have any insights on uh how well this uh browser relay attack uh can be prevented by conditional access policies for sence while not in a GitHub context but for Azure 0 for example um to be honest I don't um I think if you can help me so I mean uh it can be to a large degree prevented depending on your conditional access policies right but um I think there are options to make sure that there are company devices used to log in and I think in that case that uh should prevent that type of use case um because the browser on the server the

attacker does not have the company device certificate for example um but I'm sure there are also complexities in how to configure that and there are probably our ways how to it up thank you

yeah uh one question I had was this isn't much less of a cat and mouse than uh um the the browser running things trying to protect itself like the app on the browser running things to try to protect itself uh where they can have JavaScript check things that you try you can then try to buypass and that's a lot of work as you mentioned but if the vendors started caring about these attacks they could apply uh the the same kind of techniques that uh they use to for example uh get rid of bots social media uh where they will try to detect your uh scripted browser and uh maybe use the webg apis to fingerprint you and

stuff like that um are you like are you seeing these ever like will the vendors care about this are you seeing any of this being detected um and does this work in other things than GitHub I know know that uh in some scenarios um they try to detect when you're running a headless browser for example but if you use a custom implementation of course is like really hard to detect and also trying to block Bots for example this kind of activity might be expensive or might um might uh might be quite difficult to implement uh so I think right now it's becoming more and more common so there might be protections coming but for now I think it's quite

successful mostly everywhere see I see thank you more questions one

second uh thank you for the talk and jumping in for your colleagues uh you mentioned um the Legacy mechanisms and that the at the end we are talking about downgrade attacks and that um the legy mechanisms should be removed now there's of course a reason why they are there what would be um an efficient and working alternative I mean it's yeah yeah like you mean alternative of of not using a fallback method exactly because there are reasons why we have fallback methods we are fallback methods to logging in somewhere and um your token is broken you're on holidays whatsoever ever I mean one of the Simple Solutions would be well you're locked out um what uh is

there anything you can think about or your colleagues did for um solving that like I think it's a It's Tricky question because uh of course uh fallback Legacy methods are not secure but also it's like hard to implement for a company like um just a hardware MFA authentication right and it's like a a tricky question uh as as a recommendation uh we we said that okay throw throw throw uh throw your fullback method and just keep to uh UB or just keep to to Hardware authentications but we know it's not uh it's not like a super sustainable way because because of some processes might be affected by this so it's a it's a really tricky scenario

and it's a Solutions obviously have some fiction and compromises always so and so we also think it really depends on who the target is right so for GitHub they offer a service for free to a mass of people so they need some flows that are more or less automated so I can understand that they want to have this type of fallback um but I think if now you pay for GitHub for whatever reason as an organization you should have the option to have a stronger control if you organization has some support flows right and I think the the fallback method is if you are company that you have some support people and you have a

support flow to recover your access of course you need to also be able to secure your support flow right that your customer support doesn't just unlock any account when they are called um but I think for for high security organizations they should be able to afford a support flow that lets people recover their accounts thanks I think I saw another hand at this side right okay do we have more questions that's mean at the very

back be very quick but um I noticed during the demo that the target was logging on and so we also got logged on was it that both of of them will be logged on to the same session so is it like current or did I not understand that part yes as far as I know yeah we reuse this like you you can use both sessions you just steal the session and and redirect the target to the oral side so you can keep both thank you okay any more hands it's good I think you're safe I think there's one more question uh what just came to my mind is um how would the situation change if you

use an app um for multiactor authentication like a lot of banks um are doing or a GitHub also as a way to confirm the login by the app I think sorry say again how would the situation look like if it use an app to confirm the login like um is it also possible to circumvent that um for example like what that what you were doing with using the multiactor authentication by SMS um was that also possible to um use that as a way to log in I think when you are prone to introduce a code for example like Microsoft yeah for example I think in the end it's always a term of like social engineering right if you can

trick the user into doing that and if you can get the code from the real website as long as you can do that it's harder but is uh just building a trustful story and and conducting it so it's definitely harder

but more heads good now you're say thank you again H thank