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!
Monday, December 12, 2016
Live Response Collection - Bambiraptor
Good news everyone!! After a fairly busy year, the past few weeks I have finally had enough down time to work on adding some long overdue, and hopefully highly anticipated, features to the Live Response Collection. This version, named Bambiraptor, will fix some of the small issues that were pointed out in the scripts, including making it a little more pronounced that I am using the Belkasoft RAM Capture tool in the collection, such as an additional file created in both the 32 and 64 bit folder, respectively, at the request of the great folks over at Belkasoft, the autoruns output being the csv file twice, rather than one csv and one easy to read text, some additional logic built in to ensure that the "secure" options actually secure the data, and a couple of minor text fixes to the output. The biggest change is on the OSX side though, so without further ado, we shall dive into that!
The biggest change on the OSX side is the addition of automated disk imaging. It uses the internal "dd" command to do this, so again, be aware, that if you suspect your system may be SEVERELY compromised, this may generate non-consistent output. If that is the case, you should probably be looking at a commercial solution such as Blackbag's Macquistion to acquire the data from a system. Remember, the Live Response Collection is simply another tool in your arsenal, and while it does have some pretty robust capabilities, always be sure that you test and verify that it is working properly within your environment. I have tried my best to ensure that it either works properly or fails, but as there are different flavors of Mac hardware and software, it gets harder and harder to account for every possibility (this, along with the fact that I see way more Windows systems than OSX/*nix systems in the wild, is why my development plan is Windows first, followed by OSX, followed by *nix).
With the addition of the disk imaging, there are now a total of three scripts that you can choose to run on an OSX system. They are self explanatory, just like on the Windows side. However, unlike the Windows side, you MUST run specify to the script that you are running it with super user privileges, or else the memory dump & disk imaging will not occur. The Windows side is set to run automatically as Administrator as long as you click the proper pop ups, OSX, to my knowledge, does not have this option).
I have purposely held off on releasing "secure" options on the OSX side because I want quite a bit more real-world testing to hopefully identify and eliminate any bugs before starting to secure the data automatically. The reason for this, is again, it is more difficult to account for small changes that can have a big impact on the OSX side and I want to ensure the script(s) are working as properly as possible before encrypting and securely erasing collected data, as I don't want to have to run process(es) more than once because one system does not understand a single quotation mark compared to a double quotation mark.
I hope you have a chance to use the Live Response Collection, and as always, if you identify any issues with it, if you find any bugs, or if there are any additional features you would like to add, please let me know. The roadmap for next year includes rewriting portions of the OSX script to better adhere to bash scripting security guidelines, adding secure options to the OSX side, and adding memory dump & automated disk imaging to *nix systems, as well as continuing to add updates and features to the scripts as needed and/or requested.
LiveResponseCollection-Cedarpelta.zip - download here
MD5: 7bc32091c1e7d773162fbdc9455f6432
SHA256: 2c32984adf2b5b584761f61bd58b61dfc0c62b27b117be40617fa260596d9c63
Updated: September 5, 2019
Friday, October 28, 2016
Public release of "allyouruarecordarebelongtous" Perl script
Hello again readers and welcome back! This blog post is going to be short, as the primary purpose is to publicly announce a new script, cleverly titled "allyouruarecordrebelongtous.pl", which was in my "Who Watches The Smart Watches" presentation that I gave at OSDFCon on October 26. This Perl script will allow the user to parse out data from SQLite databases associated with Under Armour Record stored on an Android device and present that information in an easy to read format. Please let me know if you have any questions or comments about the script.
If you would like to see the slides from my OSDFCon presentation, you can view them here.
The script itself can be found on our github page:
https://github.com/brimorlabs/allyouruarecordarebelongtous
Please note, in order to run the script you may have to install some Perl modules. On a Windows system, to do this open a command prompt and paste the following command:
ppm install DBI DBD::SQLite DateTime IO::All
On OSX/*nix system, open a terminal window and paste the following command:
sudo cpan DBI DBD::SQLite DateTime IO::All
Additionally, I would very much like to thank Jessica Hyde (https://twitter.com/B1N2H3X) for helping me generate some test data and helping with code reivew and script output formatting. There is no way I would have been able to put this all together in 2 1/2 weeks without her help!
Friday, June 24, 2016
Public release of "allyourpebblearebelongtous" Perl script
Hello again readers and welcome back! This blog post is going to be fairly short, as the primary purpose is to publicly announce a new script, cleverly titled "allyourpebblearebelongtous.pl". This Perl script will allow the user to parse out data from a SQLite database associated with Pebble data stored on either an iOS or Android device, and present that information in an easy to read format. Please let me know if you have any questions or comments about the script.
If you would like to see the slides from my SANS presentation, you can view them here
Parsed notifications from Android device |
Parsed notifications from iOS device |
The script can be found on our newly created github account:
https://github.com/brimorlabs/allyourpebblearebelongtous
Please note, in order to run the script you may have to install some Perl modules. On a Windows system, to do this open a command prompt and paste the following command:
ppm install DBI YAML DBD::SQLite Data::Plist DateTime IO::All
On a Linux system, open a terminal window and paste the following command:
sudo cpan DBI YAML DBD::SQLite Data::Plist DateTime IO::All
Additionally, I would like to thank Adrian Leong (https://twitter.com/Cheeky4n6Monkey), Mari DeGrazia (https://twitter.com/maridegrazia), and Heather Mahalik (https://twitter.com/HeatherMahalik) for their help in gathering and testing the collected data.
Friday, April 22, 2016
Very quick blog post on "squiblydoo"
Hello again readers, it has been busy over here for the past few months, but over the past few days there has been some really interesting research done by Casey Smith (@subTee) regarding COM+ objects, specifically using regsvr to access external sites (cough cough potentially malware), cleverly named "squiblydoo". The original blog post is here. Apparently it leaves almost no trace on the system, for which I reference a quick look at running it in Noriben:
Brian Baskin's tweet regarding results of Noriben looking at "squiblydoo" |
Now, I am sure some of you are thinking, "so what, <fill in thoughts here>", because after all, several of the things in the past that we were supposed to get all spun up about (most recently, the debacle that was "badlock" have really turned out to be a lot of marketing hype and not much else). Well, this is something that you should take note of. Until/unless regsvr32 is modified to change the way that it works, there is very little left on the system itself to show that something bad happens. There have been several well respected experts weighing in on this issue (browsing for it will likely give you more information than you ever wanted to know) and the general consensus is that this is pretty worrying.
Twitter weighs in on "squiblydoo" |
So, what to do? It is very likely that how often regsvr32 actually gets called is dependent on what you do in your environment. It really should never hit the internet, for anything (I will note that statement has not been fully determined yet) but what I have found to be the most successful solution thus far in limited testing is using the open source tool "Process Notifier". It is pretty easy to set up, you run the proper flavor (32 or 64 bit), choose "Processes to Monitor", then type "regsvr32.exe" as your process name to check, choose "Started" and click "Add", then "Apply" and "Save"
Process Notifier options |
Adding regsvr32 to the processes to monitor list |
Then you can set up the email alerts under "E-mail Settings", by choosing your send to email address, the message subject, and message body, and even take a screenshot if you'd like under "Message". The next part is very important, under "SMTP" I highly recommend creating a one time throw away gmail account for this, because it does save the account password in plain text on the system. Once you do all of these steps, again choose "Apply" and "Save"
"Message" options under E-mail Settings |
"SMTP" options under E-mail Settings |
My emailed alert on regsvr32, complete with screenshot! |
Command prompt running regsvr32 captured in the screenshot! |
It is important to note that if this was used maliciously, having the alert on regsvr32 means it will take the screenshot when the process starts. So you may not see your shell (or whatever else was done) but you should see the site/file that it references. And even if it downloads malware that cleans up after itself and squiblydoo, the email should have been sent before that actually happens, so (fingers crossed) you will hopefully get a notification. And if you do get a notification, this would probably be a really good time to at least start gathering data from the system, most likely at least memory and volatile data (hmm...sounds like a good job for the Live Response Collection!)
Unfortunately this only works for finding regsvr32 and does not have the capability to look for urls in the command itself, but it should be a pretty useful quick check to see if it gets called. And if your environment actually does use regsvr32 on a regular basis, this will get very noisy and a different solution will have to be found. It is also very important to remember that there still has to be a considerable amount of testing to try to remedy this situation, so this (or any other method) should only be a temporary fix until a long-term, viable, solution is presented, which is what we are all working toward!
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
MD5: 7bc32091c1e7d773162fbdc9455f6432
SHA256: 2c32984adf2b5b584761f61bd58b61dfc0c62b27b117be40617fa260596d9c63
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!
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)