DomainTools Fingerprinting Threat Actors with Web Assets
•
0 likes•729 views
This document discusses techniques for fingerprinting threat actors using their web assets. It describes how programmers often reuse code across sites for convenience. Web assets like JavaScript files, CSS files, and images can provide fingerprints to link related malicious infrastructure. The document gives an example of finding related domains tied to a threat actor by searching for a unique CSS filename on Google. It suggests this approach could be extended to more sophisticated techniques like file-level hashing and coding style analysis to profile web threats similar to how malware is analyzed.
More Related Content
What's hot
What's hot (20)
Similar to DomainTools Fingerprinting Threat Actors with Web Assets
Similar to DomainTools Fingerprinting Threat Actors with Web Assets (20)
Recently uploaded
Recently uploaded (20)
DomainTools Fingerprinting Threat Actors with Web Assets
- 1. Fingerprinting Threat Actors Using Web Assets MAY 2018
- 2. Often when seeing a new threat on our network, we want to do more than just block one IP or type of traffic at our firewalls Using an IP address or attack traffic signature to locate other attacker infrastructure can prevent further incursions from that attacker… Pivoting across pieces of information like: • Nameserver • Whois information • Email domains • Shared hosting Exploratory Threat Intelligence
- 3. 1. When hunting down a specific adversary, particularly when attribution is a goal, operational security is king! 2. It is becoming more common for malicious actors to disguise things like domain registrations, to use throwaway contact info, etc 3. When web content is involved, it’s more difficult for an attacker to create custom content for every site they use 4. Even when content is different, coding style and shared resources represent an investment in time that is difficult to re-work for each malicious site Exploratory Threat Intelligence
- 4. In general, when we refer to web assets, we mean files that are loaded into the main HTML of a site via html tags. Examples include: • Javascript files (via <script> tags) • CSS files (via <link> tags) • Images (via <img> tabs) What do we mean by web assets?
- 5. • Programmers are lazy… threat actors are no exception • Reusing css and js files is easier than writing new ones from scratch • The set of third party files loaded into an HTML document and the order in which they are loaded is highly variable, and therefore a good potential fingerprint • Added javascript and css in stock files and/or inline to the html are easy ways for “lazy” programmers to get script code into pages, and generally this code will not be unique across their infrastructure How can we fingerprint infrastructure using web assets?
- 6. What do these assets look like? A website has a set of tags that indicate resources to load. In particular: • CSS • Javascript These tags allow for modularization so they make great targets for infrastructure linking.
- 7. Simple Connection Searching THIS IS A TRIVIAL, BUT REAL EXAMPLE, USING A DOMAIN SURFACED FROM ALIENVAULT’S OTX
- 8. Simple Connection Searching THIS IS A TRIVIAL, BUT REAL EXAMPLE, USING A DOMAIN SURFACED FROM ALIENVAULT’S OTX
- 9. Simple Connection Searching IF WE LOOK AT THIS DOMAIN IN IRIS, WE SEE SOME SIMILAR INFORMATION ABOUT ITS PROFILE
- 10. We saw some js and css resources on this page already… Let’s pick one that looks interesting and see what google might be able to find for it. Let’s look at: aurblue/components.css Picking something to search on
- 11. There’s nothing specific in this CSS file that looks interesting, but reuse is very very common. The hardest part of this process is searching based on a component that is common across a threat actor’s infrastructure, but NOT generally common. Maybe we’ll get lucky! Picking something to search on
- 12. Most of these sites are websites that track metadata on other sites that reveal connected domains. These sites DO provide information about the sites we are looking at, which gives us some indications of where to look next. Simple Connection Searching SEARCHING OUR UNIQUE FILENAME ON GOOGLE DOES, IN FACT, YIELD INTERESTING RESULTS:
- 13. We got lucky this time, but often searching in this simplistic way, we would find javascript and CSS resources that are common to many sites. Examples: • JQuery • Bootstrap • Foundation • Etc Simple Connection Searching
- 14. Related Domains IF WE LOOK AT SOME OF THE DOMAINS WE GUESSED WOULD BE RELATED, WE FIND A PREVIOUSLY UNSEEN CORRELATION:
- 15. Related Domains IF WE LOOK AT SOME OF THE DOMAINS WE GUESSED WOULD BE RELATED, WE FIND A PREVIOUSLY UNSEEN CORRELATION:
- 16. Related Domains IF WE LOOK AT SOME OF THE DOMAINS WE GUESSED WOULD BE RELATED, WE FIND A PREVIOUSLY UNSEEN CORRELATION:
- 17. Related Domains IF WE LOOK AT SOME OF THE DOMAINS WE GUESSED WOULD BE RELATED, WE FIND A PREVIOUSLY UNSEEN CORRELATION:
- 18. The two domains we investigated, though not directly related, both have a related domain (surfaced by Iris) that shares a common email address: This shows us that even with a very straightforward approach, we can begin to associate malicious actors infrastructure via web assets. Related Domains
- 19. As we’ve said a few times, we got lucky on this case, but the same technique can be used in a more general fashion to explore related domains. What about a less trivial case? <link… <script… <image… <meta… File level hashing and analysis Function level hashing and analysis Coding style and comment analysis Increasinglevelofsophistication
- 20. These techniques have been used in malware analysis for some time, but we need to extend them to the web space. • Signatures • External network calls • Code reuse • Code style • Runtime analysis Malware analysis, but for the web
- 21. Advertisers have been using similar techniques for tracking users across the web for some time… why shouldn’t we use it to track attackers? OR… reverse browser fingerprinting? Browser attributes: • the User agent header • the Accept header • the Connection header • the Encoding header • the Language header • the list of plugins • the platform • the cookies preferences (allowed or not) • the Do Not Track preferences (yes, no or not communicated) • the timezone • the screen resolution and its color depth • the use of local storage • the use of session storage • a picture rendered with the HTML Canvas element • a picture rendered with WebGL • the presence of AdBlock • the list of fonts Page attributes: • Meta tags • Link tags • Script tags • Inline scripts and styles • External object references • iframes • Web frameworks • What else?