Sandboxes, OPSEC, and Doing No Harm
- Playfairsec
- Apr 5, 2019
- 5 min read
Mining sandbox services for fun, and definitely not profit. We'll call it awareness.
One of the most common mistakes I see when working on a CIRT team is the blind upload of files and URLs to sandbox services. While sandboxes are great tools that help you make a determination of whether a file is malicious or not, sometimes using them can be detrimental, or even catastrophic to the organization you are protecting and the individuals within it. It is easy to find PDFs submitted by wary users or security team members that contain invoices, resumes, and even financial information on these sandbox sites. A passage of the Hippocratic oath comes to mind here: "First, do no harm." Network security personnel are not doctors by any stretch, nor (in most cases) is network security a life or death scenario, but some things we do to help can actually have the opposite effect. I think that security professionals should do their due diligence to ensure that they "first, do no harm."
Sandboxes: Good for Research, Bad for OPSEC
Sandbox services are awesome. I jumped on the hype train for various sandbox sites like Malwr, Hybrid-Analysis, and AnyRun a long time ago, and they are still the best way of breaking complex malware into its constituent parts, API calls, persistence mechanisms, and hiding techniques. However, as I find myself looking for samples to tear open for blog fodder, occasionally I happen onto a PDF, spreadsheet, or Word document. It won't be marked as malicious, but as many pieces of malware can now evade sandboxes by requiring human interaction, I check it out anyway. After all, I don't want to look for the known evil, I want the hidden evil. The context of the file name may look similar to known themes used by most larger malware campaigns: Invoice_###.pdf, john_doe_cv.doc, remittance.pdf, etc. Looking further into it, in many cases email addresses, contact information, and employment history for the unfortunate prospective employee are made public for all to see. While many people have their resumes on sites like LinkedIn, this is not a forum on which they chose to release their information. I also found it much easier to locate these types of sensitive files via a search engine on sandbox sites rather than on LinkedIn. Beyond that, the fact that someone decided to upload an untrusted copy of a resume to a malware analysis site can also indicate some other things that, while less serious, can still be more than the individual wanted to convey to the world, namely that they are looking for a new job in the first place.
In the inverse case, uploading actual malware to a sandbox can tip the organization's hand to any adversaries who happen to be monitoring for specific samples to be submitted. This means that if a targeted attack is occurring on your network, the adversary now knows what you know in regards to detecting them on the network, and can react accordingly (i.e. changing command and control, going silent to avoid additional discoveries, or last ditch mass-exfiltration).
Aiding and Abetting
Recently, a new form of card skimming technique has been observed in the wild. It circumvents the messy work of breaking into PoS systems, fiddling with hardware in meatspace, and that whole memory scraping business by injecting a script into a vulnerable checkout system; in most cases Magento online retail platform, targeted by MageCart. The way this works is by injecting an "OnChange" event listener into the fields in the checkout, so as the fields are populated, the data that the customer is entering is POSTed out in real-time, before the information is even submitted to the retailer. The sensitive data is usually obfuscated with simple base64 encoding and appended directly to the URL.
The issue that this creates for the incident responder is that the indicator URL observed on the network now has the victim's minimally encoded credit card information, address, phone number, password, or any number of sensitive pieces of information in it. It is now a piece of threat intelligence as well as evidence and personally identifiable information. Unfortunately, in some cases the URL's status as threat intelligence either takes precedence over its status as evidence or PII, or the analyst is unsure of the URL in the first place, and either submits it to a sandbox service, or to an intelligence sharing platform. In fact, submitting these URLs to sandboxes for analysis actually re-submits compromised data to the exfiltration domain, in a way ensuring that the adversary receives the information in the event technical security controls prevented the initial outbound communication. During my research for this blog post, I was able to find credit card numbers, passwords, email addresses, and phone numbers in URLs submitted to these services.
While I have no doubt the analysts who uploaded these indicators had the best intentions with their actions, the fact remains that their actions made the issue worse. I also wonder whether or not the incident was ever handled in the manner that the specific threat requires. And while it is absolutely none of my business whether or not it was, this question is something that analysts would be well-served to ask themselves on a daily basis.
Scrubbing it all away
After my research, I made the vendors aware of the more egregious pieces of information I found on their platforms, and most were removed quickly. Unfortunately when it concerns resumes and invoices uploaded to sandbox sites, I think the problem is not so easily addressed (I did not provide any examples in the body of the post for this reason). In my opinion, to stop turning these sites into an OSINT goldmine for adversaries, many analysts will need to engage in a little more critical thought before uploading. Determining the answers to questions like: "could this do more harm than good?", or "what tools do I have at my disposal to analyze this locally?", or "what what does this [file|URL] consist of, and what is its purpose?" could help in many ways. Not only can these questions improve OPSEC of a security team, but they can also improve analytical skills, as manual analysis brings analysts closer to the actual badness of malware, which in turn has the effect of "demystifying" malware (and idea that I hope to explore in a future post). As I stated earlier in this post, I still think that sandboxes are great, but they are not a magic bullet for incident response. Analysts should first determine the context and purpose of an artifact, or use manual analysis tools to look at them before uploading, because even if the results do not come back with a red icon next to them, that may not actually be a good thing.
*ANALYST NOTE: Most indicators have been purposely scrubbed from these images, as it is very easy to find personal information using the breadcrumbs of the URI strings. My goal is to bring light to an issue, not make it worse.
Comentários