Credential Attack Recon Detection: How Tooling Fail And How To Reduce False Positives by Abi Waddell

thank you hi everyone my name is abby waddell and i currently work as a managing consultant with the trustwave spider labs emea team the difa team so that's digital response uh sorry digital forensics and instant response i'm going to talk about credential attack recon detection and how user entity behavior analytics and network intrusion tools fail and how false positives can be reduced so basically organizations throw money at the latest tooling and but these still allow credential attacks and other recon activities to slip through the net undetected and so this talk will demonstrate what tooling uh traditionally is flagged several ways that they can be improved and stop almost certain indicators of malicious and unauthorized recon activities

principally around credential compromise so the attack signatures described not will not only significantly reduce the likelihood of network and application compromise but will also reduce the instances of false positives and improve detection and attack prevention earlier on in the cyber attack kill chain so this is all based on research on the methodology of recent successful credential attacks and by looking at the offering of current network tooling which basically fails to detect some key signatures at the recon stage of an attack so here are some of the rules that network tooling traditionally filters on some of them obviously very important and necessary and pretty much standard in most applications so what we've got is communications to

and from blacklisted ip addresses and domains accounts that escalate privileges the use of any use of administrative accounts use of previously breached credentials unusual system deployments and changes unusual account changes network request request rate concurrent logins and multiple account lockouts system access and changes and unusual data transfers

so i'm going to describe some of the attack signatures that could be incorporated into the tooling to detect and prevent credential attack recon activities which aren't presently in in these tool sets so this is basically being observed through researching some of these major tool tooling applications at the moment so the use of nonsense or gibberish words should be detected as detected as this is indicative of web form credential recon activity so such words may be used when quickly filling out a dummy registration form to gain legitimate access to a site or to test site responses uh to form entries so gibberish words are more likely to be used if the form filled out um is if the

form is filled out many times over and the way to screen such gibberish words is to look for the presence of two or more letters which are not usually paired in the english language anyway so for instance a double y or h and also the presence of three or more of the same letter uh for so for instance aaa or bbb so the presence and also the presence of all numbers in a form field which expects to receive alpha alphabet characters um such as first and last name fields nobody has a number in their name the presence of special characters which again where they would not be expected such as a physical address and the use of non-existent domains

after the at symbol so if anyone's ever done any pen testing and you're quickly check checking a site to see what the responses are it's just easier to put in a load of garbage words you don't really need to fill in an actual address if you're just literally just trying to get away with testing the minimum but obviously attackers use that technique too especially if they're cycling through several credentials so one can screen for repeat form post requests but the presence of these non-standard words or characters basically reduces the likelihood of any false positives another typical recon action when testing credentials is to ascertain from the application's responses whether a username is legitimately in use

so once a valid username is established the attacker can focus on any password attempts first attempted will be a definitely valid username with an invalid response uh password so to test this response it's relatively easy to get this set up on a form just most most registration is free and you can do that and you can test the response this so this valid username will often be one that's been obtained through you know the legitimate but the dummy registration so the system responds to this uh initial attempt with an incorrect password message and then the attacker will try a different credential which is deliberately nonsense to see whether the application produces a different response which it does so here it shows

there is no record of this user and now that the attacker knows that the account enumeration is possible on the application they can feed in some usernames to see if they are if these particular usernames are registered on the site by checking for this specific incorrect password response so such system response patterns should be flagged especially if they happen within a short space of time again it's helpful to screen for the gibberish letters as my as per my last um so how does this uh particular screening differ from what um might already be in place in the in your tool sets so basically whilst error messages sorry whilst error messages um can may be picked up on in in your average

tool set uh screening toolset so this basically it's the order in which they're done which reduces the likelihood that this is a false positive so a genuine user is more likely to trigger an incorrect password message and or less likely there is no record of this user followed by any incorrect password messages but is much less likely to have the pattern of errors shown in this slide here so it's the order in which the error messages come through and as any as any pen tester who's ever brute forced accounts knows almost every single list of username or password entries namely ones that come built into cracking tools or ones that could be found with a quick google search such as

the top 1000 most common passwords um and obviously we've got the password list built into tools like metasploit they're fed into the um brute forcing tools unchanged so the script that iterates through each item on the list does so in the same order each time an attack detection tooling should note the first three entries of these lists and flag when they are used in this order in succession immediately as opposed to waiting until a thousand attempts are made so this will also point much more definitely to a malicious attack taking place [Music] and monitoring should be focused on web pages which contain unencoded or unencrypted user ids in the http requests as these may have a strong

likelihood of being targeted by those seeking to exploit account enumeration and compromi compromise weaknesses so user ids are often tampered with to achieve the same using web request and response proxy tools which enable post and get request parameters to be changed on the fly in order to test the application's response so it's worth flagging any requests made to such pages in a short space of time rather than blanket screening absolutely every page on your web application which obviously um it increases how much an administrator or has to to go through to detect any kind of anomalies if you can get the list of any publicly leaked credentials from previous breaches both pertaining to your company

and to other breaches and take the first few entries of such lists and feed this into the attack signatures and if you want you can also search and bring up a list of your of your company email addresses from a recent breach and then note the order of the first three entries and block or flag the connection so yeah sorry so yeah um so even if these particular accounts are not used um or no longer used or they are in use but the password has changed their use will still point to an attempted an attempted attack with a high degree of certainty and essentially that's what you want you want the intel on the source ip address or the source of

any such attempts because even if they might not be successful it provides a useful source of intel which you can then marry up to other attack behaviors that you might see further on down the line [Music] so this is something which um is probably almost certainly being flagged at the moment in your tool set but just in case um it might be worth tweaking it so you're not just screening for account login attempts using the same username but you're using your screening rapid attempts using different usernames as well and one thing a good thing to look for is flagging repetitive backlinks and onward onward links by site users so this is about detecting repetitive site

visitor user patterns looking at where they've been immediately before arriving at your company site and then where did they go afterwards so if the same pattern happens repeatedly in a short space of time this could basically indicate a credential reuse or credential stopping attack the attack will be will be testing to see if a particular credential works on the site's notice and if there are a lot of credentials to test the same sites could be used over and over again in the same order not always but it it just adds to the attack intel pool so the proceeding and onward sites don't have to be malicious or suspicious so suspicious sites could include say email

finder applications leak credentials for sales site scraping tools and so on but in this example it just shows benign sites being visited so what we have is the visitor has gone to twitter as it again this is not a proof that they are doing anything suspicious but a credential reuse attack will look at hey i'm going to try and test it on twitter then go on to your company's site see if it works on your company site and then leap on to bbc or whatever another benign site because they're testing the credentials in more than just your company's site um and so as i said this could be for innocent reasons but it's just added to the

attack and tell really the overall profile of what's going on and again if you can marry this up with other other behaviors then you've got a better picture so the the series quite important to note the series of repeating patterns doesn't have to happen one after the other but i would say in a short space of time so if you're if you're seeing this but interspersed with other requests but overall say in the space of an hour you're getting a huge proportion of the this particular pattern then that could be fed into um into the attack tooling signatures [Music] flag non-existent sub-domains and web directories in urls so site visits to predictable but non-existent url

directories indicate high probability of suspicious recon activity so typical attempts will be on the login and the administrative directories so for instance by prefixing the site name with vpn or webmail or mail etc and also appending predictable directories after the site name such as slash mail cpanel slash login obviously your site your webs infrastructure will may have indeed these these um prefixes um but it's just again it's adding to the pool if you're seeing a lot of these guest attempts especially if you don't have these sites these directories in place then it could indicate credential recon activity i'm also also important to spot a possible signs of tampering um on the upper level directories which are presented by an

application so for instance in this example www.test.com user equals 2000 um and so basically instead of the link that the site would automatically direct visitors to so so if if you so that so the the actual company page or whatever would be ampersand home page start forward slash account but if you're seeing and that follows after the user equals 2000 but if you're seeing a direct hit on the user equals 2000 instead of the full redirect then it indicates potential tampering with that parameter so in this particular case the attacker will be looking to see um tampering with the 2000 to see what are the what responses come from changing the 2000 to other numbers

and if you're seeing a lot of these url combinations in a short space of time then it's likely to be suspicious so again especially if these urls are not actually part of your application [Music] so normal versus suspicious behavior shouldn't be flagged for for internal corporate users but also for external site visitors so one particular behavior that would be deemed for is to look at site actions immediately following any registration so a normal user will probably browse on specific links shop for a product i'm not sorry sorry got the wrong slide here um and so yeah a normal user would go to your site register on your site browse for specific links uh shop for a product

or post a message for instance within say an hour of initial registration but an attacker on the other hand would attempt some sort of url parameter manipulation or code injection within this first hour [Music] so the use of sequential letters and numbers being used in either the password username or any other in user interaction points should be flagged so examples of this include password one password two and so on any any series of numbers or other sequences so this is less likely to warrant flagging but could still be relevant depending on your industry so it's useful to cross-reference any non-existent physical address entries made by users on your company websites or return to sender postal mail

addresses with other behaviors so attackers may as part of any enumeration create dummy addresses as part of a fake registration and this will basically this may tie into any return snail mail which uses the same dummy address so one example of this is when the dummy registration automatically triggers the sending of a form or other printed material in the postal mail which then needs further action from the user in order to complete the registration process and get an account on the site a high number of two-factor authentication verification messages also unknown device or browser warnings and also forgot password messages to an account could point to account compromise which could also be used as a

springboard to access other sites external to your company or access your company's system from from this compromised account so if your site isn't a direct target but has weak security and attacker will use your site to get control of an account and any credentials in order to then attack sites other sites which the user may have an account on and obviously vice versa so a member of staff's personal email for instance maybe maybe used to compromise their their own company so the equivalent company account so any recon or account testing may trigger the sending of these system messages to a particular email address in your business so you basically need to flag whenever a high number of these messages are sent

to us to single or multiple email accounts in a short space of time [Music] some larger companies have a list of those staff members called vips who have additional monitoring and protection and such staff are usually the top level executives in addition to maintaining a list of these individuals there should be a list of new or less experienced employees and those employees for which a generous helpful positive attitude is an attribute such as customer service agents or sales as these are all likely to be phishing targets so attractive targets are those such as employees who who basically anyone is attractive if they present a weak link in the chain it doesn't have to be the top ceo it could be the new

the new junior staff member who's just joined so what we've got is you know examples of this is a new hire who's who's not well versed in company security policies uh a sales person who's eager to make a sale a customer service agent who really wants to help the project manager has an upcoming product launch deadline and and basically yes so some security for some employees is seen to come at the expense of the effectiveness of their role and attackers know how to play on this

um it's worth flagging calls to follow on extension numbers from automated switchboards so look at in particular calls made to administrative function codes which may have default or weak pin code set also look at the high volume of calls to different voice voicemail boxes within a short space of time when messages are just simply not left and also look at multiple account pin code lockouts on voicemail boxes so basically why is this important because the company phone system can often provide a useful source of recon in addition to obviously presenting a whole host of other attacks but i'm focusing on the recon the attack credential attacks here so if an attacker deliberately makes lots and lots of calls out of hours and

reaches the voicemail boxes of staff the resulting automated greetings and those mailboxes will often provide the name of the staff member and their job role and likewise multiple calls to voicemail boxes where no messages are left points to possible recon activity um so yeah and lots of these calls in a short space of time could also indicate pin number guessing and pin numbers are usually only protected with between four to six digits and that still represents a viable attack vector screen or blacklist iep addresses belonging to well-known rotational proxy services so such proxies facilitate web scraping and brute force activities and also hide any source ip addresses free vpn uh ip address service ip addresses should also be screened

so many of these services rotate addresses from a large pool of ip addresses and if you know what these are then if you can blacklist or flag them [Music] screen for identical interval times between each login attempt where the user agent is the same now this is different to traditional screening of the number of login attempts in a certain time period which most attack uh network detection tooling does screen for so automated brute forcing tools can change their speed for each login attempt but they can still be identified as suspicious from the interval timing of the login request so not whether there's hundreds made in a short space of time but whether each time the submit enter

button is clicked there's it has almost the same interval of time between them so here are some examples so what we've got is traditional flagging of number of requests in a specific specified time period might be say a hundred requests per or more per minute then suddenly the alarms get triggered additional flagging could also be done based on the similarity of interval between each login request so when an automated tool and tack tool is being used the interval period is more likely to be the same so in this case five seconds between each login attempt but if the login attempts are done manually again could also be someone who's trying to guess credentials there would be some varying time intervals as

shown in this example so a genuine user so yeah in in this sorry yeah the manual attempts so we've got varying sort of four seconds seven seconds and so on and then a genuine user attempting a set of logins they will usually this will usually get happen because they've forgotten their password or because they've had an inactive session timeout so their intervals will show a wider differences between in each request so what you're looking for is the manual login attempts above and the automated ones here at the bottom of this slide

sorry [Music] um if you flag it's good also to flag repeated login attempts over a greater time period so at least a few hours traditional screening looks at a set of failed or successful logins within a short space of time so for instance 10 concurrent attempts within 10 minutes so such suspicious login should be monitored in case the attacker is trying repeated attempts across a longer period of time in order to get around any failed account login restrictions so traditional tooling i say any only sort of looks at that short ten minute period accounts lockout and that's the end of it you should be looking at a a few hours because in this example what we see is five attempts are made on

the joe bloggs account but because the the attacker knows that after the sixth attempt the account will be locked out he or she stops trying so they try five attempts then wait a long period 75 minutes in this case because the attacker knows that the account uh guesting can resume after this time obviously different applications have different restrictions on this and and he knows that after 75 minutes the account lockout or any kind of restriction will be removed and then he resumes the account guesting with five more tries followed by waiting for 75 minutes and so on so so the wrong account tries should be screened by your by your tooling it's a mistake to think that

attackers just try a thousand attempts and you know or tens of thousands no sometimes with credential reuse attack they know roughly what the passwords might be so they don't need to run tens of thousands of attempts it might be that they've got a list of 20. so it's worth their while waiting a few hours to cycle through these 20 ones without them triggering any kind of alarm [Music] monitor email forwarding rules to for attack of assistance so i basically discovered last year that the outlet desktop app can have forwarding rules created that bypass a company's exchange security rules so even if there's a company-wide exchange server policy to prevent automatic forwarding of emails to external accounts this can be

circumvented by setting up a rule to add any external email in the email holders cc field using the outlook desktop app so while the genuine account holder could spot unauthorized rules if they scrutinize the cc fields or sent emails these are not always checked or at least not straight away so even if there's a few days delay this could present a serious data exploration issue once an attacker can create this rule in a compromised mailbox and so you should be flagging these forwarding rules so this is an example here of creating a rule called send to hacker any emails that this unwitting user sends uh externally or internally the email will automatically add the external yahoo address to the cc field

so here i send an internal email to joe blogs who works in my company and as you can see the rule adds the external attacker address in the cc field without my knowledge obviously if i do scrutinize my sent mails and i happen to see that in the cc field then yeah that the trick has been rumbled but how long does that take who actually checks that all the time even if a few emails get through that's still a risk so i did contact microsoft and they said there is no workaround or patch that was a year or so ago so not great so to conclude improved attack behavior detection signatures need to be included

in the network tooling which give a high indication of malicious activity at the recon stage of the cyber attack kill chain so an approved awareness of recon activities will provide a better picture of an attacker based on their methods and adding to standard threat indicators of compromise and it goes without saying that reducing false positives will help focus efforts in a more productive way and yeah hopefully this has highlighted how credential attacks can be detected with better rule sets thank you for listening

if anyone has any questions i'm happy to answer afterwards i don't know what the time okay thanks

thank you is it on oh there thank you so much for this amazing talk i just had one quick question so you've listed out a lot of these rule sets and a lot of ways to identify compromise credentials via performing recon activity through your uh responses to these incidents have you found a selected few that are you know like the silver bullet if that exists right these are the things that if you see are highly correlated with compromise credentials it depends on the company in the business really what sort of setup you've got and obviously the tooling that you have in place i haven't been on the screening side of the network uh on the network side to

look at that in any great depth to know oh yeah that's definitely one or that's definitely one but it's definitely something that the um the manufacturers the developers of these applications should be considering um so from my my threat intel and my forensics work that i've done and pen testing as well i would say all of these are very important again some some businesses it depends what they do um there would be more emphasis on on some of these signatures than others um but ultimately if it reduces the the noise and you can actually hone in on what is almost certainly a malicious attack that saves work for everybody and if it's a no-brainer to add these

signatures in then it's worth doing thank you all right thank you very much abby uh brandon of course