OSINT for Incident Response (Part 2)
Be sure to read PART 1!
Metadata and a New-Fashioned Bank Robbery
Let’s face it, some cases are just more interesting than others and, when you do incident response for a living, you’ve got to find joy in your work where you can. Sometimes, after the initial call with a customer, you just want the case. You’d almost do it for free (we don’t suck at capitalism quite that much!) because of the allure, the mystery, the challenge. This was one of those cases.
The customer was a financial services institution with locations throughout the United States, highly regulated, with highly segregated technology and workflow. They had defense-in-depth security solutions from the endpoint to the perimeter, micro-segmentation throughout their environment, extensive auditing and monitoring capabilities, complete with separation of duties for all workflow involving significant financial transactions. In short, they were checking all the “cybersecurity best practices” boxes and then some. But they were still getting robbed.
I’m sure all financial services institutions suffer from some measure of loss due to fraudulent transactions. But FFSI Bank (“Fictitious Financial Services Institution Bank,” because that’s just how creative I am) was seeing a significant increase in fraudulent activity for a specific type of transaction over a period of recent months. Because they ran such a tight ship, they’d caught and stopped most of the transactions, but despite extensive, internal analysis, they’d failed to identify or stop the source.
On the initial call, they were clearly a very smart and capable group and seemed frustrated and a little embarrassed that they were unable to figure this out on their own. Could it be an insider threat with multiple, internal collaborators? Might it be some new, extremely stealthy malware? Was it possible that their multiple layers of security and segmentation had somehow been breached from the outside?
The part that isn’t fun about engagements like this is preparing the proposed statement of work. “Hey, Derek, how many hours you think this is going to take?” To which Derek replies, “Oh, somewhere between 40 and 400.” Exactly. I mean, these are smart folk with some pretty cool capabilities. To do “better,” we’ll need to dig deeper, further, wider. But first… OSINT.
We went back to the customer, warned them that this could get expensive, but proposed spending a few hours performing some external analysis first, to see what we could “see” and learn from the internet.
As per “OSINT for Incident Response – Part 1,” a compromise usually occurs because something changed, from misconfigurations to zero-day exploits to end-user behaviors, and the avenue of attack is most frequently the internet. If the internet knows, the threat actors (bank robbers?) know, and as incident responders, we need to know!
I have a standard 5-minute OSINT for IR process (see Part 1) which I ran through. I was fairly certain this wasn’t going to be that easy, but it was still a good place to start and yielded some useful information, though no smoking guns.
Much of OSINT is reviewing intentionally “public” information, like DNS records, then sleuthing out tangential or inferred data. For example, if FFSI has a DNS “A” record mapping the name “portal.ffsibank.com” to 50.x.x.100 and another mapping “support.ffsibank.com” to 50.x.x.102, we can hypothesize that 50.x.x.101 likely belongs to FFSI (subject to validation of course). If I pull on that particular thread, lookup 50.x.x.101 and find reverse DNS records that map to “dev.ffsibanking.com,” which is slightly different (“bank” vs “banking”) but pretty clearly related, I now have additional domains to enumerate!
Sadly, in this case, I pulled on all the “IP address and DNS/domain” threads and nothing unraveled. So, I scratched my head a bit, mused about how to go “deeper, further, wider,” and pondered the question: “What is the most granular search query I can perform that still uniquely identifies the customer?” I can’t very well search for “F” or “FF” and obtain useful results, but what if I base OSINT searches on “FFSI” or “FFSIB” or “ffsibank?”
So, I visited https://shodan.io, ran these queries, and came up empty. Then I visited https://leakix.net and got a promising hit for “ffsibank.” Apologies that the images are so redacted, but they are hopefully still representative! Ironically, the result below is an actual, fairly recent hit on a related search term (‘visit_log.txt’ – see below) for an entirely different non-fictional financial institution.
Based on my leakix.net results, I suddenly have multiple additional threads to pull on, including a new IP address, a domain name, a service provider (Digital Ocean), a geographical location, etc. Which do I pull on first? Honestly, I want to browse the site in question, but I want to do it safely and from an unattributable IP, as I don’t want to tip my hand to the threat actor if I can avoid it. Browserling to the rescue! Browserling is basically a hosted, virtualized browser session primarily designed for web testing and development. You can use it for free, with some limitations, or pay a very reasonable price to extend features: www.browserling.com
I started by visiting the bare URL, “mail.redacted-pid.com,” where I was torn between doing my personal banking or trying my luck at some digital slots! Apologies for the intentionally blurry screenshot, as it is actually from case data.
Why would a Cambodian gambling site have references to “ffsibank?” And isn’t this supposed to be a “mail” server? The plot thickens! Let’s see if we can find the “ffsibank” reference while “safely” browsing through Browserling.
Browsing the site contents reveals an “ffsibank” folder. The contents of that folder turn out to be high-quality imitations of the “FFSI” Bank customer login portal.
Smoking gun? Yeah, I think so. But we’re not done yet! What else can we see, learn, extrapolate? Do you think this is the only site attempting to mirror the “FFSI” Bank customer portal?
Returning to the parent directly, as above, note the “visit_log.txt” file. We want to be very careful accessing content on the site, so we can attempt it via Browserling or perhaps you have another, authorized mechanism for visiting “suspicious” websites, like curl or wget (command-line web browsers) on an isolated virtual machine (that’s an entirely different blog post!). In this case, the file was legitimately just a text file, containing user-agent strings (information about the browser used for access) and IP addresses for everyone who’d been duped into visiting the folders in the “Index of” image above. A smoking gun and a gold mine in one fell swoop!
What about other potentially malicious sites? Let’s pull on the “certificate” thread and see what we can find! Next, I visited https://search.censys.io to leverage their certificate services search features. Since modern browsers are very aware of “insecure” sites or certificate to domain name misalignments, the threat actors are often smart enough to use “https” and a valid certificate. After all, they can now easily do so for free.
On search.censys.io, I’ll start with a “Certificates” wildcard search ‘names: “ffsib*”’ first, then, depending on results, I’ll likely drill down to a specific, free certificate services provider, e.g. “Let’s Encrypt.”
How do you spell “bank” anyway? When I first performed the wildcard name search, there were approximately 425+ returned results, many of which were likely valid/legit. But I noticed a pattern of three or four certificates with “common name” (CN) and a slight misspelling of the word “bank” (as above). Re-running the search and filtering on “Let’s Encrypt” as a certificate services provider, it became clear that there were indeed many more forged, malicious sites being used to target “FFSI” Bank customers.
At this point, we’re ready to report back to the customer with some pretty significant insight into targeted attacks against their customers. We’re also able to derive high-fidelity intelligence to help identify existing malicious sites and monitor for new malicious sites, e.g. “ffsibank” directory, “visit_log.txt” file, “Let’s Encrypt” associated certificate, etc. And I’m happy to report that we accomplished all of this well below the “40 to 400” hour initially projected timeframes. OSINT for the win!
As mentioned in “OSINT for IR – Part 1,” being a digital-forensics and incident response consultant is largely about unanswered questions. When we engage with a client, they know something bad happened or is happening, but they are uncertain of the “how, when, where and why.” A significant component of our job is to tease out the “known knowns,” the “known unknowns,” and effectively and efficiently help the client answer their questions. OSINT for IR can be extremely valuable and should be part of the investigative process.
Case #3: Metadata and Denial of Service via Domain Account Lockouts
In the next installment of “OSINT for IR,” we’ll continue our metadata sleuthing adventures and unravel an enterprise-wide, Active Directory account lockout “denial of service” attack. Thanks for reading!
READ: PART 1
Be sure to tune in next Thursday, 3/14, at 1pm EDT for Patterson’s webcast:
Demystifying Windows Malware Investigations w/ Patterson Cake
You can register HERE!
Ready to learn more?
Level up your skills with affordable classes from Antisyphon!
Available live/virtual and on-demand
