Friday, October 28, 2016
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:
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
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:
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
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
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-Allosaurus.zip - download here
Updated: January 12, 2016
Thursday, January 7, 2016
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!
Thursday, November 12, 2015
Hello again readers and welcome back! Today we are pleased to announce the release of a new version of buatapa, updating from version 0.0.5 to 0.0.6. The changes are going to be mostly transparent for end users, but it does account for a change in the output of autoruns.csv files generated with the recently release Autoruns 13.5, which has an additional field in the output. The new version of buatapa attempts to identify if the autoruns.csv file was generated by Autoruns 13.5, or if it was generated by Autoruns 13.4 (or earlier). The parsing of the data and need for the VirusTotal API key to do the VirusTotal lookups is exactly the same.
And as a super awesome bonus feature, it also performs queries of ThreatCrowd and returns data if it is found. In order to not have to write an additional timer (the ThreatCrowd API is limited to one query every 10 seconds) I included the ThreatCrowd lookup with the VirusTotal lookup, so for the purposes of buatapa you are required to have the VirusTotal API in order to perform the ThreatCrowd look ups. You can modify the script to not require that if you wish, but if you do that be sure to allot for a 10 second sleep between each query.
|Output results of buatapa 0.0.6|
In this particular instance, we have two URLs, one is for the Virus Total results of the hash:
|VirusTotal results for the ZeroAccess malware sample|
and the other is for the Threat Crowd results of the hash:
|ThreatCrowd results for the ZeroAccess malware sample|
If it has been noted on ThreatCrowd you can go through the information listed to look for additional information on the malware, including domains and IP addresses, in an effort to help combat/detect other instances of the malware within your environment. Plus, the pictures are really nice!!
buatapa_0_0_6.zip - download here
Updated: November 11, 2015
Friday, October 30, 2015
Hello again readers and welcome back! For us, October consisted of a lot of traveling giving presentations about the Live Response Collection at BSides Raleigh, Anne Arundel Community College, WomenEtc. (Richmond, Virginia), and the Open Source Digital Forensics Conference (OSDFCON). I just posted the presentation that I gave at OSDFCon on slideshare, if you would like to view the slides!
NOTE: I made some slight variations on the presentation at each venue, so if you attended one (or more!) of my talks you will notice that the slides are similar, but may not be exactly what you saw.
All of the events that I spoke at were great, but I was most impressed with OSDFCon this year. There was an incredible lineup of speakers at the event and the venue and presentation was fantastic (And thanks again goes out to Ali for all of her hard work, mainly behind the scenes, to ensure the event went smoothly!). There were quite a few students and other new entrants into the DFIR community at this years event, which is always great to see. Hopefully that trend continues, as there is not a single person within the DFIR community who has gotten to where they are today without the help, collaboration, and communication of others!
Not to give away any spoilers, but I am working on some exciting updates for the Live Response Collection, primarily on the OSX side, that I hope to have out before the end of the year. I am always looking for anyone who can devote any time or resources for beta testing, so if you want to help please do not hesitate to reach out!