I blogged about getting started in the industry back in April (as well as here and here), and after having recently addressed the question on an online forum again, I thought I'd take things a step further. Everyone has their own opinion as to the best way to 'get started' in the industry, and if you look wide enough and far enough, you'll start to see how those who post well thought out articles have some elements in common.
In the beginning...
We all start learning through imitation and repetition, because that's how we are taught. Here's the process, follow the process. This is true in civilian life, and it's even more true in the military. You're given some information as to the "why", and then you're given the "how". You do the "how", and you keep doing the "how" until you're getting the "how" right. Once you've gotten along for a bit with the "how", you start going back to the "why", and sometimes you find out that based on the "why", the "how" that you were taught is pretty darned good. Based on a detailed understanding of the "why", the "how" was painstakingly developed over time, and it's just about the best means for addressing the "why".
In other cases, some will start to explore doing the "how" better, or different, questioning the "why". What are the base assumptions of the "why", and have they changed? How has the "why" changed since it was first developed, and does that affect the "how"?
This is where critical thinking comes into play. Why am I using this tool or following this process? What are my base assumptions? What are my goals, and how does the tool or process help me achieve those goals? The worst thing you could ever do is justify following a process with the phrase, "...because this is how we've always done it." That statement clearly shows that neither the "why" nor the "how" is understood, and you're just going through the motions.
Years ago, when I had the honor and the pleasure of working with Don Weber, he would regularly ask me "why"...why were we doing something and why were we doing it this way? This got me to consider a lot about the decisions I was making and the actions I was taking as a team leader or lead responder, and I often found that my decisions were based not just on the technical aspects of what we were doing, but also the business aspects and the impact to the client. I did not take offense at Don's questions, and actually appreciated them.
Learn to program
Lots of folks say it's important to learn a programming language, and some even go so far as to specify the particular language. Thirty-five years ago, I started learning BASIC, programming on an Apple IIe. Later, it was PASCAL, then MatLab and Java, and then Perl. Now it seems that Python is the "de facto standard" for DFIR work...or is it? Not long before NotPetya rocked the world, the folks at RawSec posted an article regarding carving EVTX records, and released a tool written in Go. If you're working on Windows systems or in a Windows environment, PowerShell might be your programming language of choice...it all depends on what you want to do.
There is a great deal of diversity on this topic, and I'd suggest that the programming language you choose should be based on your needs. The main point is that learning to program helps you see big problems as a series of smaller problems, some of which must performed in a serial fashion. What we learn from programming is how to break bigger problems into smaller, logical steps.
Engage in the community
Within the DFIR "community", there's too much "liking" and retweeting, and not enough doing and asking of questions, nor actively engaging with others. Not long ago, James Habben posted an excellent article on his blog on "being present", and he made a lot of important points that we can all learn from. Further, he put a name to something that I've been aware of for some time; when presenting at a conference, there's often that one person how completely forgets that they're in a room full of other people, and kidnaps and dominates the presenter's time. There are also those who attend the presentation (or training session) who spend the majority of their time engaged in something else entirely.
Rafal Los recently posted a fascinating article on the SecurityWeek web site. I found his article well-considered and insightful, and extremely relevant. It's also something I can relate to...like others, I get connection requests on LinkedIn from folks who've done nothing more than clicked a button. I also find that after having accepted most connection requests, I never hear from the requester again. I find that if I write a blog post (like this one) and share the link on Twitter and LinkedIn, I'll get "likes" and retweets, but not much in the way of comments. If I ask someone what they "like" about the article...and I have done this...more often than not the response is that they didn't actually read it; they wanted to share it with their community. Given that, there is no difference between having worked on writing and publishing the article, and not having done so.
Engaging in the community is not only a great way to learn, but also a great way to extend the community itself. A friend recently asked me which sandbox I use for malware analysis, and why. For me to develop a response beyond just, "I don't", I really had to think about the reasons why I don't use a sandbox. I learned a little something from the engagement, just as I hope my friend did, as well.
An extension of engaging in the community is to write your own stuff. Share your thoughts. Instead of clicking "like" on a link to a blog post, add a comment to the post, or ask a question in the comments. Instead of just clicking "like" or retweeting, share your reasons for doing so. If it takes more than 140 characters to do so, write a blog post or comment, and share *that*.
I guess the overall point is this...if you're going to ask the question, "how do I get started in the DFIR industry?", the question itself presupposes some sort of action. If you're just going to follow others, "like" and retweet all the things, and not actually read, engage, and think critically, then you're not really going to 'get started'.
Tuesday, August 22, 2017
Friday, August 18, 2017
Updates, New Stuff
Specificity
The folks at Talos recently posted an interesting article, "On Conveying Doubt". While some have said that this article discusses "conveying doubt" (which it does), it's really about specificity of language. Too often in our industry, while there is clarity of thought, there's a lack of specificity in the language we use to convey those thoughts; this includes all manner of communication methods; not only reports, but presentations and blog posts. After all, it doesn't matter how good you or your analysis may be if you cannot communicate your methodology and findings.
Ransomware
Ransomware is a pretty significant issue in the IT community, particularly over the past 8 months or so. My first real encounter with ransomware, from a DFIR perspective, started last year with a couple of Samas ransomware cases that came in; from a perspective external to my employer, this resulted in two corporate blog posts, one of which was written by a colleague/friend, and ended up being one of the most quoted and referenced blog posts published. Interestingly enough, a lot of aspects about ransomware, in general, have continued to evolve since then, at an alarming rate.
Vitali Kremez recently posted an interesting analysis of the GlobeImposter ".726" ransomware. From an IR perspective, where one has to work directly with clients, output from IDAPro and OllyDbg isn't entirely useful in most cases.
However, in this case, there are some interesting aspects of the ransomware that Vitali shared, specifically in section VI.(b).; that is, the command line that the ransomware executes.
Before I go any further, refer back to Kevin's blog post (linked above) regarding the evolution of the Samas ransomware. At first, the ransomware included a copy of a secure deletion tool in one of it's resource sections, but later versions opted to reduce the overall size of the executable. Apparently, the GlobeImposter ransomware does something similar, relying on tools native to the operating system to run commands that 'clean up' behind itself. From the embedded batch file, we can see that it deletes VSCs, deletes user's Registry keys related to lateral movement via RDP, and then enumerates and clears *all* Windows Event Logs. The batch file also includes the use of "taskill" to stop a number of processes, which is interesting, as several of them (i.e., Outlook, Excel, Word) would immediately alert the user to an issue.
FortiNet recently published an analysis of a similar variant.
Online research (including following #globeimposter on Twitter) indicates that the ransomware is JavaScript-based, and that the IIV is via spam email (i.e., "malspam"). If that's the case (and I'm not suggesting that it isn't), why does the embedded command line include deleting Registry keys and files associated with lateral movement via RDP?
Marco Ramilli took a look at some RaaS ransomware that was apparently distributed as an email attachment. He refers to it as "TOPransomware", due to a misspelling in the ransom note instructions that tell the victim to download a TOP browser, as opposed to a TOR browser. This is interesting, as some of Samas variants I've seen this year include a clear-text misspelling in the HTML ransom note page, setting the font color to "DrakRed".
I also ran across this analysis of the Shade ransomware, and aside from the analysis itself, I thought that a couple of comments in the post were very interesting. First, "...has been a prominent strand from around 2014." Okay, this one is new to me, but that doesn't really say much. After all, as a consultant, my "keyhole" view is based largely on the clients who call us for assistance. I don't claim to have seen everything and know everything...quite the opposite, in fact. But this does illustrate the differences in perspective.
Second, "...spread like many other ransomware through email attachments..."; this is true, many other ransomware variants are spread as email attachments. The TOPransomware mentioned previously was apparently discovered as a .vbs script attached to an email. However, it is important to note that NOT ALL ransomware gets in via email. This is an important distinction, as all of the protection mechanisms that you'd employ against email-borne ransomware attacks are completely useless against variants such as Samas and LeChiffre, which do not propagate via email. My point is, if you purchase a solution that only protects you from email-borne attacks, you're still potentially at risk for other ransomware attacks. Further, I've also seen where solutions meant to protect against email-borne ransomware attacks do not work when a user uses Chrome to access their AOL email, and the system/infrastructure gets infected that way.
On August 7, authorities in the Ukraine arrested a man for distributing the NotPetya malware (not ransomware, I know...) in order to assist tax evaders. According to the article, he isn't thought to be the author of the destructive malware, but was instead found to be distributing a copy of the malware via his social media account so that companies could presumably infect themselves and not pay taxes.
Recently, this Mamba ransomware analysis was posted; more than anything else, this really highlights one of the visible gaps in this sort of analysis. As the authors found the ransomware through online searches (i.e., OSINT), there's no information as to how this ransomware is distributed. Is it as an email attachment? What sort? Or, is it deployed via more manual means, as has been observed with the Samas and LeChiffre ransomware?
The Grugq recently posted thoughts as to how ransomware has "changed the rules". I started in the industry, specifically in the private sector, 20 yrs ago this month...and I have to say, many/most of the recommendations as to how to protect yourself against and recover from ransomware were recommendations from that time, as well. What's old is new again, eh?
Cryptocurrency Miners
Cylance recently posted regarding cryptocurrency mining malware. Figure 7b of the post provides some very useful information in the way of a high fidelity indicator..."stratum+tcp". If you're monitoring process creation on endpoints and threat hunting, looking for this will provide an indicator on which you can pivot. Clearly, you'll want to determine how the mining software got there, and performing that root cause analysis (RCA) will direct you to their access method.
Web Shells
The PAN guys had a fascinating write-up on the TwoFace web shell, which includes threat actor TTPs. In the work I've done, I've most often found web shells on perimeter systems, and that initial access was exploited to move laterally to other systems within the network infrastructure. I did, however, once see a web shell placed on an internal web server; that web shell was then used to move laterally to an MS SQL server.
Speaking of web shells, there's a fascinating little PHP web shell right here that you might want to check out.
Lifer
Retired cop Paul Tew recently released a tool he wrote called "lifer", which parses LNK files. One of the things that makes tools like this really useful is use cases; Paul comes from an LE background, so he very likely has a completely different usage for such tools, but for me, I've used my own version of such tools to parse LNK files reportedly sent to victims of spam campaigns.
Want to generate your own malicious LNK files? Give LNKup a try...
Supply Chain Compromises
Supply chain compromises are those in which a supplier or vendor is compromised in order to reach a target. We've seen compromises such as this for some time, so it's nothing new. Perhaps the most public supply chain compromise was Target.
More recently, we've recently seen the NotPetya malware, often incorrectly described as "ransomware". Okay, my last reference to ransomware (for now...honest) comes from iTWire, in which Maersk was able to estimate the cost of a "ransomware" attack. I didn't include this article in the Ransomware section above because if you read the article, you'll see that it refers to NotPetya.
Here is an ArsTechnica article that discusses another supply chain compromise, where a backdoor was added to a legitimate server-/network-management product. What's interesting about the article is that it states that covert data collection could have occurred, which I'm sure is true. The questions are, did it, and how would you detect something like this in your infrastructure?
Carving for EVTX
Speaking of NotPetya, here's an interesting article about carving for EVTX records that came out just days before NotPetya made it's rounds. If you remember, NotPetya included a command line that cleared several Windows Event Log files
The folks who wrote the post also included a link to their GitHub site for the carver they developed, which includes not only the source code, but pre-compiled binaries (they're written in Go). The site includes a carver (evtxdump) as well as a tool to monitor Windows Event Logs (evtxmon).
The folks at Talos recently posted an interesting article, "On Conveying Doubt". While some have said that this article discusses "conveying doubt" (which it does), it's really about specificity of language. Too often in our industry, while there is clarity of thought, there's a lack of specificity in the language we use to convey those thoughts; this includes all manner of communication methods; not only reports, but presentations and blog posts. After all, it doesn't matter how good you or your analysis may be if you cannot communicate your methodology and findings.
Ransomware
Ransomware is a pretty significant issue in the IT community, particularly over the past 8 months or so. My first real encounter with ransomware, from a DFIR perspective, started last year with a couple of Samas ransomware cases that came in; from a perspective external to my employer, this resulted in two corporate blog posts, one of which was written by a colleague/friend, and ended up being one of the most quoted and referenced blog posts published. Interestingly enough, a lot of aspects about ransomware, in general, have continued to evolve since then, at an alarming rate.
Vitali Kremez recently posted an interesting analysis of the GlobeImposter ".726" ransomware. From an IR perspective, where one has to work directly with clients, output from IDAPro and OllyDbg isn't entirely useful in most cases.
However, in this case, there are some interesting aspects of the ransomware that Vitali shared, specifically in section VI.(b).; that is, the command line that the ransomware executes.
Before I go any further, refer back to Kevin's blog post (linked above) regarding the evolution of the Samas ransomware. At first, the ransomware included a copy of a secure deletion tool in one of it's resource sections, but later versions opted to reduce the overall size of the executable. Apparently, the GlobeImposter ransomware does something similar, relying on tools native to the operating system to run commands that 'clean up' behind itself. From the embedded batch file, we can see that it deletes VSCs, deletes user's Registry keys related to lateral movement via RDP, and then enumerates and clears *all* Windows Event Logs. The batch file also includes the use of "taskill" to stop a number of processes, which is interesting, as several of them (i.e., Outlook, Excel, Word) would immediately alert the user to an issue.
FortiNet recently published an analysis of a similar variant.
Online research (including following #globeimposter on Twitter) indicates that the ransomware is JavaScript-based, and that the IIV is via spam email (i.e., "malspam"). If that's the case (and I'm not suggesting that it isn't), why does the embedded command line include deleting Registry keys and files associated with lateral movement via RDP?
Marco Ramilli took a look at some RaaS ransomware that was apparently distributed as an email attachment. He refers to it as "TOPransomware", due to a misspelling in the ransom note instructions that tell the victim to download a TOP browser, as opposed to a TOR browser. This is interesting, as some of Samas variants I've seen this year include a clear-text misspelling in the HTML ransom note page, setting the font color to "DrakRed".
I also ran across this analysis of the Shade ransomware, and aside from the analysis itself, I thought that a couple of comments in the post were very interesting. First, "...has been a prominent strand from around 2014." Okay, this one is new to me, but that doesn't really say much. After all, as a consultant, my "keyhole" view is based largely on the clients who call us for assistance. I don't claim to have seen everything and know everything...quite the opposite, in fact. But this does illustrate the differences in perspective.
Second, "...spread like many other ransomware through email attachments..."; this is true, many other ransomware variants are spread as email attachments. The TOPransomware mentioned previously was apparently discovered as a .vbs script attached to an email. However, it is important to note that NOT ALL ransomware gets in via email. This is an important distinction, as all of the protection mechanisms that you'd employ against email-borne ransomware attacks are completely useless against variants such as Samas and LeChiffre, which do not propagate via email. My point is, if you purchase a solution that only protects you from email-borne attacks, you're still potentially at risk for other ransomware attacks. Further, I've also seen where solutions meant to protect against email-borne ransomware attacks do not work when a user uses Chrome to access their AOL email, and the system/infrastructure gets infected that way.
On August 7, authorities in the Ukraine arrested a man for distributing the NotPetya malware (not ransomware, I know...) in order to assist tax evaders. According to the article, he isn't thought to be the author of the destructive malware, but was instead found to be distributing a copy of the malware via his social media account so that companies could presumably infect themselves and not pay taxes.
Recently, this Mamba ransomware analysis was posted; more than anything else, this really highlights one of the visible gaps in this sort of analysis. As the authors found the ransomware through online searches (i.e., OSINT), there's no information as to how this ransomware is distributed. Is it as an email attachment? What sort? Or, is it deployed via more manual means, as has been observed with the Samas and LeChiffre ransomware?
The Grugq recently posted thoughts as to how ransomware has "changed the rules". I started in the industry, specifically in the private sector, 20 yrs ago this month...and I have to say, many/most of the recommendations as to how to protect yourself against and recover from ransomware were recommendations from that time, as well. What's old is new again, eh?
Cryptocurrency Miners
Cylance recently posted regarding cryptocurrency mining malware. Figure 7b of the post provides some very useful information in the way of a high fidelity indicator..."stratum+tcp". If you're monitoring process creation on endpoints and threat hunting, looking for this will provide an indicator on which you can pivot. Clearly, you'll want to determine how the mining software got there, and performing that root cause analysis (RCA) will direct you to their access method.
Web Shells
The PAN guys had a fascinating write-up on the TwoFace web shell, which includes threat actor TTPs. In the work I've done, I've most often found web shells on perimeter systems, and that initial access was exploited to move laterally to other systems within the network infrastructure. I did, however, once see a web shell placed on an internal web server; that web shell was then used to move laterally to an MS SQL server.
Speaking of web shells, there's a fascinating little PHP web shell right here that you might want to check out.
Lifer
Retired cop Paul Tew recently released a tool he wrote called "lifer", which parses LNK files. One of the things that makes tools like this really useful is use cases; Paul comes from an LE background, so he very likely has a completely different usage for such tools, but for me, I've used my own version of such tools to parse LNK files reportedly sent to victims of spam campaigns.
Want to generate your own malicious LNK files? Give LNKup a try...
Supply Chain Compromises
Supply chain compromises are those in which a supplier or vendor is compromised in order to reach a target. We've seen compromises such as this for some time, so it's nothing new. Perhaps the most public supply chain compromise was Target.
More recently, we've recently seen the NotPetya malware, often incorrectly described as "ransomware". Okay, my last reference to ransomware (for now...honest) comes from iTWire, in which Maersk was able to estimate the cost of a "ransomware" attack. I didn't include this article in the Ransomware section above because if you read the article, you'll see that it refers to NotPetya.
Here is an ArsTechnica article that discusses another supply chain compromise, where a backdoor was added to a legitimate server-/network-management product. What's interesting about the article is that it states that covert data collection could have occurred, which I'm sure is true. The questions are, did it, and how would you detect something like this in your infrastructure?
Carving for EVTX
Speaking of NotPetya, here's an interesting article about carving for EVTX records that came out just days before NotPetya made it's rounds. If you remember, NotPetya included a command line that cleared several Windows Event Log files
The folks who wrote the post also included a link to their GitHub site for the carver they developed, which includes not only the source code, but pre-compiled binaries (they're written in Go). The site includes a carver (evtxdump) as well as a tool to monitor Windows Event Logs (evtxmon).
Wednesday, August 02, 2017
Document Metadata
Okay, yeah, so I've been blogging a lot over the past couple of months about extracting document metadata as part of gathering threat intelligence.
This handler diary provided analysis of "malspam pushing Emotet", and this follow up post illustrated how to conduct static analysis of the document itself. I have used several of the tools mentioned, but had not yet heard of "vipermonkey", and open-source VBA emulator. Used in conjunction with oledump.py, you can really get a lot of traction with respect to static analysis of the malicious document.
While the second handler diary post focuses on analysis of the malicious macro, what neither post does is illustrate the document metadata. Below is the output of wmd.pl, run against a sample downloaded from VT:
C:\Perl>wmd.pl d:\cases\maldoc\maldoc
--------------------
Statistics
--------------------
File = d:\cases\maldoc\maldoc
Size = 215040 bytes
Magic = 0xa5ec (Word 8.0)
Version = 193
LangID = Russian
Document has picture(s).
Document was created on Windows.
Magic Created : MS Word 97
Magic Revised : MS Word 97
--------------------
Summary Information
--------------------
Title : sdf
Subject : df
Authress : admin
LastAuth : admin
RevNum : 2
AppName : Microsoft Office Word
Created : 26.07.2017, 11:51:00
Last Saved : 26.07.2017, 11:51:00
Last Printed :
--------------------
Document Summary Information
--------------------
Organization : home
From the Wired article:
Eventually, Ash sent the staffer an email with a Microsoft Excel attachment for a photography survey. She asked him to open it on his office network, telling him that it would work best there. After a month of trust-building conversation, he did as he was told. The attachment promptly launched a malicious macro...
So, this really illustrates the dedication of these threat actors...they establish a persona, including social media "pocket litter", and spend time developing a relationship with their target. As a very small part of her research, Allison took a look at the metadata embedded within the Excel spreadsheet, and found that the user information referred to "Mia Ash". This further illustrated the depths to which the threat actors would go in order to make the persona appear authentic; not only did they populate multiple social media sites and create a "history" for the persona, but they also ensured that the metadata in the documents sent to intended victims included the 'right' contents to support the persona. That's right, it's exactly the way it sounds...the metadata embedded in the spreadsheet specifically referred to "Mia Ash" as the authorized user of the MS Office products.
I know what you're going to say..."yeah, but that stuff can be changed/modified...". Yes, it can...but the point is, how often is that actually done? Look at the above listed output from wmd.pl...does it look as if any effort was put into modifying the metadata that populated the Word97 file?
Something I've said about Windows systems and DFIR work is that as the versions of Windows have been developed, the amount of information that is automatically recorded as malware or an adversary interacts with the endpoint environment has increased significantly. In many cases, this seems to be overlooked when it comes to developing threat intelligence for some reason; in spam and phishing campaigns, a lot of the different artifacts are examined...the contents of the email (headers, body, etc.), attachment macros, second-stage downloads, etc. But what is often missed is document metadata embedded in the attachment; Word docs, Excel spreadsheets, and even LNK shortcut files can all be rich in valuable information. One such example is looking at time stamps...when an email was sent, when a document was created, when a binary was compiled, etc., and lining all of those up to illustrate just how organized and planned out an attack appears to be.
This handler diary provided analysis of "malspam pushing Emotet", and this follow up post illustrated how to conduct static analysis of the document itself. I have used several of the tools mentioned, but had not yet heard of "vipermonkey", and open-source VBA emulator. Used in conjunction with oledump.py, you can really get a lot of traction with respect to static analysis of the malicious document.
While the second handler diary post focuses on analysis of the malicious macro, what neither post does is illustrate the document metadata. Below is the output of wmd.pl, run against a sample downloaded from VT:
C:\Perl>wmd.pl d:\cases\maldoc\maldoc
--------------------
Statistics
--------------------
File = d:\cases\maldoc\maldoc
Size = 215040 bytes
Magic = 0xa5ec (Word 8.0)
Version = 193
LangID = Russian
Document has picture(s).
Document was created on Windows.
Magic Created : MS Word 97
Magic Revised : MS Word 97
--------------------
Summary Information
--------------------
Title : sdf
Subject : df
Authress : admin
LastAuth : admin
RevNum : 2
AppName : Microsoft Office Word
Created : 26.07.2017, 11:51:00
Last Saved : 26.07.2017, 11:51:00
Last Printed :
--------------------
Document Summary Information
--------------------
Organization : home
...and from oledmp.pl:
C:\Perl>oledmp.pl -f d:\cases\maldoc\maldoc -l
Root Entry Date: 26.07.2017, 11:51:59 CLSID: 00020906-0000-0000-C000-000000000046
1 F.. 55949 \Data
2 F.. 7359 \1Table
3 F.. 4148 \WordDocument
4 F.T 4096 \ SummaryInformation
5 F.T 4096 \ DocumentSummaryInformation
6 D.. 0 26.07.2017, 11:51:59 \Macros
7 D.. 0 26.07.2017, 11:51:59 \Macros\VBA
8 FM. 88908 \Macros\VBA\ThisDocument
9 F.. 532 \Macros\VBA\__SRP_2
10 F.. 156 \Macros\VBA\__SRP_3
11 FM. 8137 \Macros\VBA\zjUb2S
12 FM. 8877 \Macros\VBA\cvDTF
13 FM. 4906 \Macros\VBA\FX9UL
14 F.. 15451 \Macros\VBA\_VBA_PROJECT
15 F.. 739 \Macros\VBA\dir
16 F.. 1976 \Macros\VBA\__SRP_0
17 F.. 198 \Macros\VBA\__SRP_1
18 F.. 98 \Macros\PROJECTwm
19 F.. 476 \Macros\PROJECT
20 F.T 114 \ CompObj
We can see that the dates displayed by both tools line up, and we can use oledmp.pl to further list the contents (raw, or hex) of the various streams.
So, how can any of this be of value, and why does any of this matter? Well, at BlackHat last week, Allison Wikoff spent a great deal of her time being interviewed about some really fantastic research that she'd conducted on the "Mia Ash" persona (here is the original SecureWorks posting of the results of her research).
From the Wired article:
Eventually, Ash sent the staffer an email with a Microsoft Excel attachment for a photography survey. She asked him to open it on his office network, telling him that it would work best there. After a month of trust-building conversation, he did as he was told. The attachment promptly launched a malicious macro...
So, this really illustrates the dedication of these threat actors...they establish a persona, including social media "pocket litter", and spend time developing a relationship with their target. As a very small part of her research, Allison took a look at the metadata embedded within the Excel spreadsheet, and found that the user information referred to "Mia Ash". This further illustrated the depths to which the threat actors would go in order to make the persona appear authentic; not only did they populate multiple social media sites and create a "history" for the persona, but they also ensured that the metadata in the documents sent to intended victims included the 'right' contents to support the persona. That's right, it's exactly the way it sounds...the metadata embedded in the spreadsheet specifically referred to "Mia Ash" as the authorized user of the MS Office products.
I know what you're going to say..."yeah, but that stuff can be changed/modified...". Yes, it can...but the point is, how often is that actually done? Look at the above listed output from wmd.pl...does it look as if any effort was put into modifying the metadata that populated the Word97 file?
Something I've said about Windows systems and DFIR work is that as the versions of Windows have been developed, the amount of information that is automatically recorded as malware or an adversary interacts with the endpoint environment has increased significantly. In many cases, this seems to be overlooked when it comes to developing threat intelligence for some reason; in spam and phishing campaigns, a lot of the different artifacts are examined...the contents of the email (headers, body, etc.), attachment macros, second-stage downloads, etc. But what is often missed is document metadata embedded in the attachment; Word docs, Excel spreadsheets, and even LNK shortcut files can all be rich in valuable information. One such example is looking at time stamps...when an email was sent, when a document was created, when a binary was compiled, etc., and lining all of those up to illustrate just how organized and planned out an attack appears to be.
Subscribe to:
Posts (Atom)