<p>Very often when I demonstrate our Threat Intelligence Platform (TIP), <a href="https://www.anomali.com/products/threatstream">ThreatStream</a> and show the breadth of <a href="https://www.anomali.com/blog/maximizing-the-potential-of-open-source-threat-intelligence-feeds">open source threat intelligence</a> we collect and curate, organizations struggle to understand that:</p><p>a. We do not have a record of every indicator that’s bad or malicious<br/> b. The definition of bad or malicious can differ from organization to organization</p><p>Take <a href="https://www.torproject.org/" target="_blank">Tor</a> as an example. If I’m a government department hosting a specific use portal with a small, select user base an anonymous connection might be something suspicious. If I’m a news organization exposing corruption or human rights abuses in a far flung geography, I would expect my sources to protect their identities and therefore access via Tor wouldn’t be unusual.</p><p>During a demonstration I might be asked to look up a specific IP address or domain, and if nothing is returned from our vast library of active observables the quality of those observables is questioned.</p><p>I’d like to highlight a few recent use cases where Anomali has shown the power of internal threat data: the threat data that is generated internally from an organization’s own logs or investigations.</p><p><strong>Account Takeovers</strong></p><p>At an online gaming company, the Security Operations Centre and Threat Intelligence teams were convinced of the value of a TIP. They gave access through to their Fraud team, who have a completely different remit and viewpoint. They couldn’t see the value of a threat intelligence platform.</p><p>A fraud investigation starts with a contact from one of their customers: “My account is missing money/credits/tokens etc.” or an alert from their SOC: “We’ve locked an account due to password guessing attempts.”</p><p>At the start of their fraud investigations the amount of data is often limited. In this specific instance, all they had was an account identifier - an email address - and the source IP address trying to access the account.</p><p>For either piece of data, they’d do a lookup to determine what  the TIP knew about the email address and the source IP address. Very often nothing would come back, which led to frustration and disappointment with the platform.</p><p>“What’s the point of threat intelligence?” they asked. We answered that, and although the data returned was still relevant, the search of these observables didn’t yield what they considered any smoking gun results. However, I recognized that they were gathering incredibly valuable internal threat intelligence.</p><p>What we proposed was that each suspected attack should have both the identifier and the attacking IP address imported into the TIP. The information (it’s no longer just data) would have appropriate tags applied (to ensure that it can be found quickly during subsequent searches) and an investigation workflow triggered for each suspected attack.</p><p>Doing this allows the Fraud team to detect patterns: Is there something in common with the accounts being attacked? Are attacks coming from the same IP address? Or maybe an IP range or Autonomous System Number (ASN)? What country are attacks coming from? Is there a pattern to when attacks take place?</p><p>Initiating the investigation workflow allows the Fraud team to start building up real intelligence. Intelligence specific to their organization is more valuable than anything they could gather through open sources because it can answer questions like - Can these attacks be linked together to form an incident? Are these regularly occurring attacks part of a campaign against us? Can we attribute these campaigns to a threat actor?</p><p>The process that the Fraud team uses has been refined over a period of time to take advantage of internal threat data. Previously, they would have added the attacking IP address and attacked account to a spreadsheet where it would sit as a forgotten historical record. Now, lists of attacking IP addresses are pushed down to their SIEM. Whenever a connection is made from one of those IP addresses, they’re alerted. If there’s a successful logon they can monitor account interactions in real time.</p><p><strong>Attacks through a VPN Provider</strong></p><p>A commercial organization we were working with was seeing regular port scans, probing, and denial of service attacks from a range of IP addresses. They investigated these series of attacks  to identify similarities, and worked out that they were all coming from a list of related IP addresses. It wasn’t a subnet range or an ASN; these were IP addresses that were all used by one specific provider of anonymous VPN services.</p><p>A search for these IP addresses in the TIP occasionally returned known observables, but most often came back empty. Why would a range of addresses used by a legitimate VPN provider (albeit one with a dubious reputation) be highlighted as malicious by  ‘the usual’ open source threat feeds? Remember, a VPN provider itself isn’t good or bad, it’s how the services are used (or abused) by their subscribers that counts.</p><p>The Threat Intelligence team put together a list of all the IP addresses used by the VPN provider. They entered these into the TIP and tagged them appropriately. Now they have a list of observables pushed to their SIEM that they can report on: how many ports scans this month? How many from the “bad” VPN provider? The metrics produced were so convincing that the decision was made to block all of the addresses at the firewall.</p><p><strong>Scans from Shodan</strong></p><p><a href="https://www.shodan.io/" target="_blank">Shodan</a> is described as “the world’s first search engine for Internet connected devices.”</p><p>Think of it as a way to find specific types of computers or IoT devices connected to the Internet using a variety of filters. Want to search for traffic lights, home heating systems, or industrial control systems? If they’re exposed on the Internet, Shodan knows about them.</p><p>Shodan itself is a fantastic tool but the information it returns can be used for both honorable and nefarious purposes. A system administrator might use Shodan to scan all of his Internet facing systems looking for data leakage or open ports that should be locked down or patched. Similarly, a hacker might use Shodan to scan all of his target’s Internet facing systems looking for data leakage or open ports that can be exploited.</p><p>Recently I spoke to an IT organization that uses Shodan extensively to scan their Internet facing systems. Shodan is considered a valuable resource and a tool  they use in the same way they use a commercial vulnerability scanner internally. In this case, the organization sees multiple ports scans on a regular basis. As a user of the Shodan service they want to distinguish between ‘legitimate’ scans (those coming from Shodan) and other, potentially malicious scans that may be a precursor to an attack.</p><p>The way they do this is by pulling a list of current Shodan servers down from SANS (i.e. external data) on a scheduled basis. The data is imported into ThreatStream, tagged appropriately, and used to populate a watchlist in their SIEM. Portscans from source IP addresses on that list are ignored. They can then take the remaining alerts and import them into ThreatStream as observables (i.e. internal data) if they don’t already exist. They then track connections from these addresses to their web-facing infrastructure.</p><p><strong>Conclusion</strong></p><p>Some of the most important threat data you can use to defend against attacks exist in your own log files. Just because an observable hasn’t been reported by someone else doesn’t mean it’s not important. In fact, the opposite is probably true: maybe you’re the first one to see a new attack or maybe it’s something specifically targeting you.</p><p>Being able to sift through events and extract observables for future tracking is invaluable and forms the basis for high fidelity internal threat intelligence.<br/> <br/> As always, once you’ve detected a threat and completed your investigation, please consider <a href="https://www.anomali.com/resources/sharing-threat-intelligence">sharing this information</a> with others: a published Threat Bulletin, through your <a href="https://www.anomali.com/isacs-sharing">ISAC</a>, through our Trusted Circle functionality, or with the wider community of threat researchers.</p><p><em>Interested in learning more about sharing? Check out <a href="https://www.anomali.com/resources/whitepapers/the-definitive-guide-to-sharing-threat-intelligence">The Definitive Guide to Sharing Threat Intelligence</a>.</em></p>