0:00 one of the most overlooked and more dangerous types of data leaks that affect software organizations are exposed git configuration files these files which are usually located in the hidden git directory at the root of the project contain all the information that is required for Version Control including the complete commit history configuration files branches and references often times at some point in a projects history especially a project that's kept in a private repository which isn't always so private as we'll soon see a file that contains different types of secret tokens gets committed to the project and even if that mistake is
0:46 caught right away and the very next commit is to remove that file it'll still be possible for anyone with access to the Project's history to go back in time and see what that file was and this is exactly what been going on with a recent malware campaign dubbed Emerald whale which so far has resulted in over 15,000 credentials and a terabyte of private data being stolen from private repos Cy dig first discovered the malware campaign when analyzing a cloud Honeypot where they noticed the list buckets command being issued for an account that they already knew had been compromised for those of you less familiar with Amazon web services the
1:31 list buckets command returns a list of all the cloud storage containers that are owned by the authenticated account that is sending the request so clearly this was the hackers trying to see what buckets they could get into from the compromised account and then they would go through those buckets to possibly see if there's any juicy information that they can sell or just extort the company for it you know hey we're going to sell this information unless you give us a bunch of money or they could gather more authentication tokens from those buckets in order to probe deeper into the organization the hackers even had one of their own buckets that they created under this account where a lot of the stolen data was being stored and once
2:17 the malicious activity was reported to AWS that bucket containing the stolen data was taken down but even amateur hackers know that the cloud is just some other guy's computer so I wouldn't be surprised if some of the juiciest data was already exfiltrated to the Hacker's personal hard drives and will show up for sale on a friendly neighborhood dark web Forum sometime in the future oh and speaking of the dark web some of the tools that the hackers were using that were discovered during the investigation into the malicious AWS bucket were believed to be purchased from an underground marketplace either on what we would traditionally think of as the dark web you know i2p tour or whatever
3:03 or in a telegram group or through some other encrypted chat app now the tools that these hackers were using were called mzr V2 and SEO V2 and there are collection of different scripts that automate this collection and validation of credentials from vulnerable host all the hacker really has to do is gather a list of IP addresses that they want to Target and feed that into the first script named gfinder Dosh which uses an open- Source tool called httpx for this scanning this tool lets you scan a lot of websites at Once In Parallel very quickly and check for things like what ports they're using
3:48 what version of TLS they're using or in this case the hackers were checking to see if these host had a particular file path that was accessible so the underlying command in the script might look something like this to check through a bunch of ips that are in the host text file and see if a gitconfig folder exists and can be accessed and if it is accessible then a second script called GHP url.py is run which uses wget to extract the content from that git config folder on that website and then uses a regx to extract the URL line from the page that contains a username an
4:35 authentication token and what type of credential it is next there's a check user script which uses github's own API to test if the credentials that were obtained in the previous step are still valid and if they are the credentials get saved in a new file to be used with the next script so now that the hackers have valid git credentials they can use those to start downloading repositories even if they're private and like I said earlier those private repos will often times have credentials hardcoded in them somewhere so the script looks through those repos for things like AWS keys and then uses AWS CLI commands to verify those credentials
5:21 and check what their capabilities are if they're able to create new users with administrative capabilities then there's a script to do that for them there there's also scripts to check for SMTP capabilities and create new SMTP credentials and verify if mail is able to be sent from those servers interestingly the script that checks if email sending works is written in JavaScript so node and npm have to be installed to the compromise AWS instance in order to run that now of course if hackers are able to send emails from from a trusted provider and those emails pass dkim checks because they're actually coming from the provider and
6:07 not from a spoofed address then that's going to allow the hackers to run a very successful spam or fishing campaign or more likely sell that option to another group that specializes in fishing imagine a group that has already been doing some reconnaissance to fish a specific Target you know figuring out how they're going to word their message and what kind of angle they're going to use to trick this person and they know personal details about that person and then they're able to send them an email that legitimately looks like it's coming from a service that they use even a person with excellent obsc might fall for a scam like that now the SEO V2 tool is very similar the main difference is
6:54 after the httpx portion of the script runs to find host with a valid git directory seov V2 uses a tool called git dumper to download all of that data from the git repo this is a code snippet from the dumpers shell script showing how the git dumper tool is used to search for different kinds of SMTP SMS and cloud provider credentials Emerald whale also did some good oldfashioned bulk web scraping and Analysis of the collected assets for cloud credentials and some were found statically defined in different JavaScript files that were being used by the victim's websites now the really obvious solution to prevent
7:40 this type of attack is to Simply never have credentials hardcoded into your project in the first place but when you're still in the development and testing phase of the project it's really handy to have an EnV file with database credentials or other tokens that are defined in it so that you don't have to copy paste that information every time you restart the program these configuration files are great for the development phase but really bad for the production phase a good way to mitigate this is to share those environment files through a separate channel so not through your VCS system and then add them to your get ignore files so that they never end up getting added to your
8:27 repository directly now now of course you still have to make sure that those configuration files don't leak from the other channel that you use to share them through which is why it's also a good idea to just use totally different credentials during the development and testing phases and the deployment SL production phase of your project that can also help with limiting internal access to your code when it's in production because if you're managing a large project with a lot of developers you probably don't want want everyone on your team to be able to touch the code base that's being used in production finally before you deploy any project it's a good idea to run it through a scanner like truffle hog to search for
9:14 hardcoded credentials it can also validate the credentials meaning it can attempt to log into them to confirm if that secret is live or not and it can give you other details about secrets in your project like who created them what resources they can access and what permissions does the secret have on those resources there's another open source tool called git leaks which used to be much faster than truffle hog although I think that might have changed since the truffle hog project was Rewritten in go starting with version 3.0 but nonetheless it's a good idea to run multiple secret scanners against your project before deployment and there's also proprietary scanners like get Guardian that can scan for these secrets
10:00 as well I would argue that this validation step for projects is even more important than looking through code comments for vulgar language so make sure that you add secret scanning to your workflow so that you don't get pwned by the lwh hanging fruit that is statically defined credentials if you enjoyed this video please like and share to hack the algorithm and check out my online store base. whenn get yourself some comfy merch like the come and finded hoodie hoodie or little Damon hoodie and 10% discount is still valid storewide for anyone paying in Monero XMR have a great rest of your day
