Welcome to the BriMor Labs blog. BriMor Labs is located near Baltimore, Maryland. We specialize in offering Digital Forensics, Incident Response, and Training solutions to our clients. Now with 1000% more blockchain!
Tuesday, January 12, 2016
Live Response Collection - Allosaurus
Hello readers and welcome back! Today we are proud to announce the newest round of updates to the Live Response Collection, specifically with a focus on some new features on the OSX side!
Improved OSX features!
The biggest change is that the OSX version of the Live Response Collection now creates a memory dump using osxpmem, as long as you run the program with root privileges. The script does the internal math, just like on the Windows side, to make sure that you have enough free space on your destination, regardless of whether or not it is an internal or external drive. I have encountered where OSX provides differently formatted results for the sizes (sometimes throwing in things like an equal sign or a random letter) and I tried to account for that as much as possible. If you encounter a bug with the memory dump please let me know and I will try to figure it out, but as I have done more and more work on the OSX side I have come to realize just how terrible OSX is. For example, some Apple programs do not work properly if it was created on Yosemite and it was running on El Capitan...so much for "it just works"! If you encounter any issues I will try to get to the bottom of it as best as I can though!
The other main OSX feature is a topic that was briefly touched on during the Forensic Lunch on Friday. Dave, Nicole, and James talked about the FSEvents Parser that they wrote. If you run the script with root privileges the script will copy the fseventsd data to the correlating destination folder, and then you can run their tool to go through the data. (NOTE: It is best to transfer the data to a Windows machine to do this, otherwise the fseventsd data may be hidden from you, depending on how the access permissions on your machine are set)
A new naming scheme!
As you may have noticed, the title is "Live Response Collection - Allosaurus". I decided to go with the names of dinosaurs to differentiate between Live Response Collection versions, which will also ensure that you are using the latest build and also to help with any bugs that may pop up. Sometimes a bug that is reported has been fixed in a newer release, but because of the old naming scheme, it wasn't immediately clear if you were actually using the latest build.
As always, please do not hesitate to contact me if you have any questions or comments regarding the Live Response Collection
LiveResponseCollection-Cedarpelta.zip - download here
Updated: September 5, 2019
Thursday, January 7, 2016
Cyber Security Snake Oil
Hello again readers and welcome back! Today's blog post is going to cover an instance, which unfortunately occurs WAY to often in the cyber-security realm, especially on the topic of "threat intelligence" or "advanced analytics" or whatever other buzzwords the marketing folks are spinning since it is now 2016. I had originally planned to write this post toward the end of the month, but the more I thought about the whole incident the angrier I got, so I am posting it much earlier than I had anticipated.
The subject of today's post involves a very large company. I have redacted their name and information at the request of the company involved and will be referring to them as "Kelvarnsen Industries" and an external company that I will call "Mountebank Labs". (FULL DISCLOSURE: I have not had any dealings, personally, with any member of Mountebank Labs but I have since spoken with several individuals who have). Apparently a few days ago, the CEO of Mountebank Labs sent an email to the CIO of Kelvarnsen Industries informing them of "an early warning about an email they have received (or are about to receive) that contained malware [sic]". A friend of mine works at Kelvarnsen Industries and asked my opinion about the email, which was flagged internally by the CIO as a phishing attempt because his first name was wrong (not just spelled wrong, his name was actually wrong), the message contained a slew of grammatical errors and sentences that made no sense, and referenced something that really did not seem possible. Honestly the most disturbing piece of the email sent from Mountebank Labs is that it appears they are actually targeting Kelvarnsen Industries in their "threat intelligence" platform:
|"Alert" information sent from Mountebank Labs CEO to Kelvarnsen Industries CIO|
I took a look at the referenced data and was able to easily determine it was email that was sent ENTIRELY internally, as the policy for Kelvarnsen Industries is to upload suspected malicious emails with attachments directly to VirusTotal. Yes, you read that 100% correctly. The email appeared to come FROM a legitimate internal user, sent TO a legitimate internal user...because....wait for it....THAT IS EXACTLY WHAT HAPPENED!!!
To take a quote from their blog post, in which they wrote about this as a "win" (with my own comments added in BOLD):
|Excerpt from blog post, with my own comments added|
Now, we can argue the merits of uploading samples to VirusTotal or doing analysis on them internally first. In this case, I personally happen to support the former, because there is no need for the internal CIRT to respond to an email that contained an attachment which solely installs a toolbar for "Decent Looking Mail Order Brides", so depending on what the VirusTotal results determines the internal escalation of the email. If an actual advanced threat group is trying to infiltrate an organization and they have a piece of malware uploaded to VirusTotal and the whole world can see it, so what? It means that they have been discovered and will probably have to come up with something new in an effort to achieve their goal of infiltrating their target. VirusTotal is simply a tool that we can use, it is not the end all be all solution (see malware, polymorphic)
There are a limited number of individuals and companies that work in our profession, but that number is growing every single day. Unfortunately this growth also brings with it individuals who misrepresent capabilities and understanding of pertinent information, but are more than happy to sell you products and services that usually come with very expensive price tags. In this particular case, it looks like Mountebank Labs is loading domains into VirusTotal and, when a hit comes back, shooting off an email to the CISO or CIO of the company and "alerting" them. While there is nothing "wrong" with that aspect of it (although frankly, I don't know how you can have the time or resources to do that, as everyone that I know has plenty of work with our own clients and don't need to put out a blanket domain search in VirusTotal in an effort to drum up work), in my opinion it is not the right thing to do.
I do perform monitoring from several data sources for my clients, and in the event of discovering data from another company, I will inform them who I am, who I work for, of exactly what I was doing, how I found their data, where they can go to find that data, how to contact me, and leave it at that. I strive to be as 100% transparent as possible because the last thing that I want to have happen is a company to think that I was the source of their data being compromised. If they want to have additional conversations that is entirely up to them and I tell them so. I want to help people protect their networks and sensitive data, regardless of whether or not they hire me to help them. If you receive an email like this, the author of the email (who will usually NOT be a CEO or a member of the sales team, it will likely be a technical employee or a manager) should answer several questions in the original message without your or your CIRT team searching for answers to these questions:
- Who exactly are you?
- What company do you currently work for?
- What were you doing when you found this information?
- Where did you find this information?
- When did you find this information?
- What is your contact information (not in a signature block, you should clearly list your contact information)
If these questions are not answered with very specific details, it is more than likely going to be just another marketing email, trying to get you to spend your money to utilize their services. Granted, this may not always be the case, but usually, it will be. When in doubt, you can always get a second opinion, which is exactly what Kelvarnsen Industries did when they contacted me regarding this issue.
This case also highlights another area of importance that I cannot stress enough. It is bad enough that CIRT/Net Defenders/etc. teams are tasked on a daily basis with detecting and thwarting attacks by adversaries. When a company's C-Suite executives receive an email like this, the teams must stop everything that they are doing in order to manage their C-Suite executive's concern and ultimately determine if an email such as this is an actual phish or is nothing more than vaguely worded and misconstrued marketing attempt (ahem...scare tactics). This also shows that unknowledgeable individuals are targeting companies, in publicly available data sources, in an effort to find out more about them in an attempt to secure a business deal. Pretty ironic that these folks are doing the EXACT same thing that adversary groups are doing: attempting to gather information for their own financial or informational gain. The irony of that is not lost on anyone! The unfortunate truth about marketing emails like this is that, just like phishing, they must work occasionally or else these unknowledgeable individuals would not send them. These teams also have enough to do on a daily basis (plus after-hours and weekends, as was the case here) without having to deal with the Marketing Persistent Threat. Blatant marketing attempts such as the one detailed in this post hurt MUCH more than they could ever possibly help!
Posted by Brian Moran at 1:22 PM 2 comments:
Labels: "BriMor Labs", "cyber security", "data breach notification", "data breach", "digital forensics", "incident response", "snake oil', cyber, DFIR, email, malware, marketing, notification, phishing, spam, virustotal
Subscribe to: Posts (Atom)