Case Studies
Brett Shavers posted a fascinating article recently, in which discussed the value of case studies throughout his career, going back to his LEO days. I've thought for some time now that this is one of the great missed opportunities of the DFIR community, that more analysts don't share what they've seen or done. At the same time, I've seen time and again the benefit that comes from doing something like this...we get a different perspective, or we learn a little bit more or new, *OR* we learn that we were incorrect about something, and find out what the real deal is...this can have a huge impact on our future work. Throughout the time I've been involved in the community, I've heard "...but I don't want to be corrected..." more than once, and to be honest, I'm not at all sure why that is. God knows that I don't know everything and if I've gotten something wrong, I'd love to know what it is so that I don't keep making the same mistake over and over again.
Taking Brett's blog post a bit further (whether he knew it or not), Phill Moore shared a post about documenting his work.
Cisco Talos Intelligence - Decoy Documents
The Cisco Talos Intel team recently blogged regarding the use of decoy documents during a real cyber conflict. What I found fascinating about this write-up was the different approach that was taken with the documents; specifically, the payload is base64-encoded and spread across the document metadata. When the document is opened, a macro reportedly extracts the segments from the metadata variables and concatenates them together, resulting in a base64-encoded PE file. The folks at Talos were kind enough to provide hashes for three decoy documents, which were all available on VirusTotal (searching for some of the metadata items returned this Hybrid Analysis link). As such, I took the opportunity to run them through my own tools (wmd.pl, oledmp.pl) to see what I could see.
The first interesting aspect of the documents is that even though the three documents were different in structure, some of the metadata (including time stamps) were identical.
For example, from wmd.pl, the three documents all contained the same information illustrated below:
Authress : Rafael Moon
LastAuth : Nick Daemoji
RevNum : 7
AppName : Microsoft Office Word
Created : 03.10.2017, 01:36:00
Last Saved : 04.10.2017, 14:20:00
From oledmp.pl, even though the first document had markedly different streams from the other two, the root entry and directory entries all had the same time stamp and CLSID:
Root Entry Date: 04.10.2017, 14:20:11 CLSID: 00020906-0000-0000-C000-000000000046
So, given the combination of identical metadata and time stamps, it's possible that the values were modified or manipulated to their values. I'd say that this is support by the fact that some of the metadata values were modified to include the
Remember, you can also use Didier Stevens' oledump.py to extract the compressed VBA macros. For example, to view the complete VBA script from the second document, I just typed the following command:
oledump.py d:\cases\maldoc\apt28_2 -s 8 -v
Shoop*, there it is...the decompressed macro script. Very nice. Maybe Cory and I should do reprise DFwOST, and do a second edition, and include stuff like this, going beyond just tools for forensics, and looking at tools that allow you to parse documents, etc.
Something I've mentioned before are some values that I saw listed in the output of 'strings' run across the documents:
CMG="6B69C77E3682368232863286"
DPB="D6D47AEB8E3DE45AE45A1BA6E55A4B8B26955AAD8AB69D9BB0FF733C04402A5B44526BEF14E0D0"
GC="4143EDEEEEEEEEEE"
Again, I've seen these before in Office documents that contain macros, most times with different values. The definition of these values can be found at the MS-OVA Project page, under the Stream example, and I haven't yet been able to determine how these fields are populated.
LNK Files
I've posted several times over the past couple of months regarding parsing metadata from LNK files that are part of an adversary's toolkit; those either sent to a target as an email attachment, or embedded in another document format, etc. US-CERT posted an alert recently that I found to be very interesting along the same lines, particularly regarding the fact that the adversary modifying Windows shortcut files as a means of credential theft. The big take-away from this information (for me) is that the adversary incorporated something that rudimentary about how the operating system functions and used it as a means for collecting credentials.
Of course, the "elephant in the room" is, why are organizations still allowing out-bound SMB traffic?
USB Devices
There's been a good bit of activity online recently regarding USB devices and Windows 10 systems. Eric Zimmerman blogged about some changes to the AmCache.hve file that include a significant amount of information about devices. Matt Graeber tweeted that "Microsoft-Windows-Partition/Diagnostic EID 1006 gives you a raw dump of the partition table, MBR, and VBR upon drive insertion", and @Requiem_fr tweeted that USB device info can be found in the Microsoft-Windows-Kernel-PnP%4Configuration.evtx Windows Event Log.
A little over 12 years ago, Cory Altheide and I published a paper on tracking USB devices on Windows XP systems, and it's been pretty amazing to see not only how this sort of thing has grown over time, but also to see the number of artifacts that continue to be generated as new versions of Windows have been released.
*Please excuse my taking artistic liberties to work in a Deadpool reference...
Monday, October 30, 2017
Saturday, October 14, 2017
Stuff
Powershell
In preparing to do some testing in a Windows 7 VM, I decided to beef up PowerShell to ensure that artifacts are, in fact, created. I wanted to make sure anything hinky that was done in PowerShell was recorded in some way.
The first step was to upgrade PowerShell to version 5. I also found a couple of sites that recommended Registry settings to ensure the Module Logging and Script Block Logging were enabled, as well.
The idea behind this is that there have been a number of cases I've worked that have involved some sort of obfuscated PowerShell...Meterpreter, stuff loaded from the Registry, stuff that's come in via LNK files attached to emails (or embedded in email attachments), etc. Heck, not just cases I've worked...look at social media on any given day and you're likely to see references to this sort of thing. So, in an effort to help clients, one of the things I want to do is to go beyond just recommending "update your PowerShell" or "block PowerShell all together", and be able to show what the effect of updating PowerShell will likely be.
DDE
There's been a good bit of info floating around on Twitter this past week regarding the use of DDE in Office documents to launch malicious activity. I first saw this mentioned via this NViso blog post, then I saw this NViso update (includes Yara rules), and anyone looking into this will usually find this SensePost blog article pretty quickly. And don't think for a second that this is all there is...there's a great deal of discussion going on, and all you have to do is search for "dde" on Twitter to see most of it.
David Longenecker also posted an article on the DDE topic, as well. Besides the technical component of his post, there's another aspect of David's write-up that may go unnoticed...look at the "Updated 11 October" section. David could have quietly updated the information in the post, but instead went ahead and highlighted the fact that he'd made a mistake and then corrected it.
USB Devices
Matt Graeber recently tweeted about data he observed in the Microsoft-Windows-Partition/Diagnostic Windows Event Log, specifically events with ID 1006; he said, "...gives you a raw dump of the partition table, MBR, and VBR upon drive insertion." Looking at records from that log, in the Details view of Event Viewer, there are data items such as Capacity, Manufacturer, Model, SerialNumber, etc. And yes, there's also raw data from the partition table, MBR, and VBR, as well.
So, if you need to know something about devices connected to a Windows 10 system, try parsing the data from this *.evtx file. What you'll end up with is not only the devices, but when, and how often.
Registry
Eric Zimmerman recently tweeted about the RecentApps key in the NTUSER.DAT hive; once I took a look at the key contents, I was pretty sure I was looking at something not too different from the "old" UserAssist data...pretty cool stuff. I also found via Twitter that Jason Hale had blogged about the key, as well.
So, I wrote a recentapps.pl and a recentapps_tln.pl plugin, and uploaded them to the repository. I only had one hive for testing, so YMMV. I do like the TLN plugin...pushing that data into a timeline can be illuminating, I'm sure, for any case involving a Windows 10 system where the someone interacted with the Explorer shell. In fact, creating a timeline using just the UserAssist and RecentApps information is pretty illuminating...using information from my own NTUSER.DAT hive file (extracted via FTK Imager), I see things like:
{1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\NOTEPAD.EXE (3)
[Program Execution] UserAssist - {1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\NOTEPAD.EXE (0)
{1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\NOTEPAD.EXE RecentItem: F:\ch5\notes.txt
...and...
{1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\WScript.exe RecentItem: C:\Users\harlan\Desktop\speak.vbs
{1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\WScript.exe (7)
[Program Execution] UserAssist - {1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\WScript.exe (0)
Each of the above two listings of three entries from a timeline all occurred in the same second, and provide a good bit of insight into the activities of the user. For example, this augments the information provided by the RecentDocs key, by providing the date and time at which files were accessed, rather than just that of the most recently accessed file. Add to this timeline entries from the DestList stream from JumpLists, as well as entries from AmCache.hve, etc., and you have a wealth of data regarding program execution and file access artifacts for a user, particularly where detailed process tracking (or some similar mechanism, such as Sysmon) is not enabled.
Eric also posted recently about changes to the contents of the AmCache.hve file...that file has, so far, been a great source of artifacts, so I'll have to go dig into Eric's post and update my own parser. From reading Eric's findings, it appears that there's been some information added regarding devices and device drivers, which can be very valuable. So, a good bit of the original data is still there (Eric points out that some of the MFT data is no longer in the hive file), and some new information has been added.
In preparing to do some testing in a Windows 7 VM, I decided to beef up PowerShell to ensure that artifacts are, in fact, created. I wanted to make sure anything hinky that was done in PowerShell was recorded in some way.
The first step was to upgrade PowerShell to version 5. I also found a couple of sites that recommended Registry settings to ensure the Module Logging and Script Block Logging were enabled, as well.
The idea behind this is that there have been a number of cases I've worked that have involved some sort of obfuscated PowerShell...Meterpreter, stuff loaded from the Registry, stuff that's come in via LNK files attached to emails (or embedded in email attachments), etc. Heck, not just cases I've worked...look at social media on any given day and you're likely to see references to this sort of thing. So, in an effort to help clients, one of the things I want to do is to go beyond just recommending "update your PowerShell" or "block PowerShell all together", and be able to show what the effect of updating PowerShell will likely be.
DDE
There's been a good bit of info floating around on Twitter this past week regarding the use of DDE in Office documents to launch malicious activity. I first saw this mentioned via this NViso blog post, then I saw this NViso update (includes Yara rules), and anyone looking into this will usually find this SensePost blog article pretty quickly. And don't think for a second that this is all there is...there's a great deal of discussion going on, and all you have to do is search for "dde" on Twitter to see most of it.
David Longenecker also posted an article on the DDE topic, as well. Besides the technical component of his post, there's another aspect of David's write-up that may go unnoticed...look at the "Updated 11 October" section. David could have quietly updated the information in the post, but instead went ahead and highlighted the fact that he'd made a mistake and then corrected it.
USB Devices
Matt Graeber recently tweeted about data he observed in the Microsoft-Windows-Partition/Diagnostic Windows Event Log, specifically events with ID 1006; he said, "...gives you a raw dump of the partition table, MBR, and VBR upon drive insertion." Looking at records from that log, in the Details view of Event Viewer, there are data items such as Capacity, Manufacturer, Model, SerialNumber, etc. And yes, there's also raw data from the partition table, MBR, and VBR, as well.
So, if you need to know something about devices connected to a Windows 10 system, try parsing the data from this *.evtx file. What you'll end up with is not only the devices, but when, and how often.
Registry
Eric Zimmerman recently tweeted about the RecentApps key in the NTUSER.DAT hive; once I took a look at the key contents, I was pretty sure I was looking at something not too different from the "old" UserAssist data...pretty cool stuff. I also found via Twitter that Jason Hale had blogged about the key, as well.
So, I wrote a recentapps.pl and a recentapps_tln.pl plugin, and uploaded them to the repository. I only had one hive for testing, so YMMV. I do like the TLN plugin...pushing that data into a timeline can be illuminating, I'm sure, for any case involving a Windows 10 system where the someone interacted with the Explorer shell. In fact, creating a timeline using just the UserAssist and RecentApps information is pretty illuminating...using information from my own NTUSER.DAT hive file (extracted via FTK Imager), I see things like:
{1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\NOTEPAD.EXE (3)
[Program Execution] UserAssist - {1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\NOTEPAD.EXE (0)
{1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\NOTEPAD.EXE RecentItem: F:\ch5\notes.txt
...and...
{1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\WScript.exe RecentItem: C:\Users\harlan\Desktop\speak.vbs
{1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\WScript.exe (7)
[Program Execution] UserAssist - {1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\WScript.exe (0)
Each of the above two listings of three entries from a timeline all occurred in the same second, and provide a good bit of insight into the activities of the user. For example, this augments the information provided by the RecentDocs key, by providing the date and time at which files were accessed, rather than just that of the most recently accessed file. Add to this timeline entries from the DestList stream from JumpLists, as well as entries from AmCache.hve, etc., and you have a wealth of data regarding program execution and file access artifacts for a user, particularly where detailed process tracking (or some similar mechanism, such as Sysmon) is not enabled.
Eric also posted recently about changes to the contents of the AmCache.hve file...that file has, so far, been a great source of artifacts, so I'll have to go dig into Eric's post and update my own parser. From reading Eric's findings, it appears that there's been some information added regarding devices and device drivers, which can be very valuable. So, a good bit of the original data is still there (Eric points out that some of the MFT data is no longer in the hive file), and some new information has been added.
Friday, October 06, 2017
Updates
Ransomware
Eric over at Carbon Black recently posted regarding the Kangaroo ransomware. Here are some cool things that Eric point out about the ransomware:
1. It's GUI based, and the folks using it to infect un-/under-protected RDP servers.
2. The ransomware time-stomps itself. While on the surface this may seem to make it ransomware difficult to find during DFIR, that's not really the case at all, and to be honest, I'm not at all sure why this step was taken.
3. The ransomware clears the System and Security Event Logs, and removes VSCs. As with the time stomping, I'm sure that clearing the Event Logs is intended to make things difficult but to be honest, most folks who've done this kind of work know (a) where to look for other artifacts, and (b) know how to recover cleared Windows Event Logs.
Eric's technical analysis doesn't mention a couple of things that are specific to ransomware. For example, while Eric does state that the ransomware is deployed manually, there's no discussion of the time frame after accessing the RDP server in which the ransomware is deployed, nor if there are any attempts at network mapping or privilege escalation. I'm sure this is the result of the analysis being based on samples of the ransomware, rather than due to responding to engagements involving this ransonware. Earlier this spring, I saw two different ransomware engagements that were markedly different. While both involved compromised RDP servers, for one, the bad guy got in, mucked about for a week (7 days total, albeit not continuously) installing Opera, Firefox, and a GIF image viewer, and then launched ransomware without ever attempting to escalate privileges. As such, only the files in the compromised profile were affected. On the other hand, in the second instance, the adversary accessed the RDP server and within 10 minutes escalated their privileges and launched the ransomware. In this case, the entire RDP server was affected, as were other systems within the infrastructure.
Types of Ransomware
Speaking of ransomware, I ran across this article from CommVault recently, which discusses "5 major types" of ransomware. Okay, that sparked my interest...that there are "5 major types".
Once I started reading the article, I became even more interested, particularly in the fourth type, identified as "Samsam". Okay, this is the name of a variant or family, not so much what I'd refer to as a "type" of ransomware...but okay. Then I read this statement:
Once inside the network, the ransomware looks for other systems to attack.
I've worked with Samsam, or "Samas" ransomware for a while. For example, I authored this blog post (note: prior employment) based on analysis of about half a dozen different ransomware engagements where Samas was deployed. In all of those cases, a JBoss server was exploited (using JexBoss), and an adversary mapped the network (in several instances, using Hyena) before choosing the systems to which Samas was then deployed. More recently (i.e., this spring), the engagements I was aware of involved RDP servers being compromised (credentials guessed), and much shorter timeframe between initial access and the ransomware being deployed.
My point is, from what I've seen, the Samas ransomware doesn't do all the things that some folks say it does. For example, I haven't yet seen where the ransomware looks for other systems. Further, going back to Microsoft's own description of the ransomware modus operandi, I saw no evidence that the Samas ransomware "scans the network"...I did, however, find very clear evidence that the adversary did so. So, a lot of what is attributed to the ransomware itself is, in reality, and based on looking at data, the actions of a person, at a keyboard.
If you want to see some really excellent information about the Samas ransomware, check out Kevin Strickland's blog post on the topic. Kevin did some really great work, and I really can't say enough great things about the work he did, and what he shared.
Windows Registry
Over on the Follow the White Rabbit blog, @_N4rr34n6_ has an interesting article discussing the Windows Registry. The article addresses setting up and using RegRipper and its various components, as well as other tools such as Corey Harrell's auto_rip and Phill Moore's RegRipper GUI, both of which clearly provide a different workflow placed over the basic code.
Podcasts
I've had the honor and privilege to be asked to be involved on a couple of podcasts recently, and I thought I'd share the links to all of them in one place, for those who are interested in listening:
Doug Brush's CyberSecurity Interviews - I've followed Doug's CyberSecurity Interviews from the beginning, and greatly appreciated his invitation and opportunity to engage
Down the Security Rabbithole with Rafal and James; thanks to both of these fine gentlemen for offering me the opportunity to be part of the work they're doing
Nuix Unscripted - Corey did a really great job moderating Chris and I, which brought things full circle; not only did Chris and I used to work together, but Chris was one of the very first folks interviewed by Doug Brush...
Investigations
Chris Woods over at Nuix (transparency: this is my employer) posted an excellent article regarding three best practices for increasing the efficiency of examinations. Interestingly enough, these are all things that I've endorsed over the years...defining clear analysis goals, collaboration, and using what has been learned from previous investigations. I want to say something about "great minds", but the simple fact is that these are all "best practices" that simply make sense. It's as simple as that.
WifiPasswordReveal
I ran across something really fascinating today..."wait," you ask, "more fascinating than making your computer recite lines from the Deadpool movie??" Well...no...but almost! Here is a fascinating article that illustrates not only the steps for how to reveal Wifi passwords on a Win7+ computer, but provides a batch file for doing so! How cool is that?
LNK Metadata
A bit ago, I'd taken a look at a Windows shortcut/LNK file from a campaign someone had blogged about, and then submitted a Yara rule to detect submissions to VirusTotal, based on the MAC address, volume serial number, and SID embedded in the LNK file. This was based on an LNK file that had been sent to victims as an attachment.
The Yara rule I submitted a while back looks like this:
rule ShellPhish
{
strings:
$birth_node = { 08 D4 0C 47 F8 73 C2 }
$vol_id = { 7E E4 BC 9C }
$sid = "2287413414-4262531481-1086768478" wide ascii
condition:
all of them
}
So, pretty straightforward. The thing is, over the past few days, I've seen a pretty significant up-tick in responses from the retro hunt, indicating a corresponding up-tick in submissions to VT. Up to this point, I'd been seeing maybe one or two detections (again, based on submissions) a week; I've received about a few dozen or so in the past two days alone. This up-tick in responses is an interesting change, particularly because I'm not seeing a corresponding mention of campaigns utilizing LNK files as attachments (to emails, or embedded in documents, etc.).
A couple of things I haven't done is note the first submission dates for the items, as well as the country from which they were submitted, and then downloaded the LNK file itself to parse out the command line, and note the differences.
So, why am I even mentioning this? Well, this goes back to Jesse Kornblum's premise of using every part of the buffalo, albeit the fact that it's not directly associated with memory analysis. The metadata in file formats such as documents and LNK files can be used to develop insight based on relationships, which can lead to attribution based on further developing the threat intelligence you already have available.
Eric over at Carbon Black recently posted regarding the Kangaroo ransomware. Here are some cool things that Eric point out about the ransomware:
1. It's GUI based, and the folks using it to infect un-/under-protected RDP servers.
2. The ransomware time-stomps itself. While on the surface this may seem to make it ransomware difficult to find during DFIR, that's not really the case at all, and to be honest, I'm not at all sure why this step was taken.
3. The ransomware clears the System and Security Event Logs, and removes VSCs. As with the time stomping, I'm sure that clearing the Event Logs is intended to make things difficult but to be honest, most folks who've done this kind of work know (a) where to look for other artifacts, and (b) know how to recover cleared Windows Event Logs.
Eric's technical analysis doesn't mention a couple of things that are specific to ransomware. For example, while Eric does state that the ransomware is deployed manually, there's no discussion of the time frame after accessing the RDP server in which the ransomware is deployed, nor if there are any attempts at network mapping or privilege escalation. I'm sure this is the result of the analysis being based on samples of the ransomware, rather than due to responding to engagements involving this ransonware. Earlier this spring, I saw two different ransomware engagements that were markedly different. While both involved compromised RDP servers, for one, the bad guy got in, mucked about for a week (7 days total, albeit not continuously) installing Opera, Firefox, and a GIF image viewer, and then launched ransomware without ever attempting to escalate privileges. As such, only the files in the compromised profile were affected. On the other hand, in the second instance, the adversary accessed the RDP server and within 10 minutes escalated their privileges and launched the ransomware. In this case, the entire RDP server was affected, as were other systems within the infrastructure.
Types of Ransomware
Speaking of ransomware, I ran across this article from CommVault recently, which discusses "5 major types" of ransomware. Okay, that sparked my interest...that there are "5 major types".
Once I started reading the article, I became even more interested, particularly in the fourth type, identified as "Samsam". Okay, this is the name of a variant or family, not so much what I'd refer to as a "type" of ransomware...but okay. Then I read this statement:
Once inside the network, the ransomware looks for other systems to attack.
I've worked with Samsam, or "Samas" ransomware for a while. For example, I authored this blog post (note: prior employment) based on analysis of about half a dozen different ransomware engagements where Samas was deployed. In all of those cases, a JBoss server was exploited (using JexBoss), and an adversary mapped the network (in several instances, using Hyena) before choosing the systems to which Samas was then deployed. More recently (i.e., this spring), the engagements I was aware of involved RDP servers being compromised (credentials guessed), and much shorter timeframe between initial access and the ransomware being deployed.
My point is, from what I've seen, the Samas ransomware doesn't do all the things that some folks say it does. For example, I haven't yet seen where the ransomware looks for other systems. Further, going back to Microsoft's own description of the ransomware modus operandi, I saw no evidence that the Samas ransomware "scans the network"...I did, however, find very clear evidence that the adversary did so. So, a lot of what is attributed to the ransomware itself is, in reality, and based on looking at data, the actions of a person, at a keyboard.
If you want to see some really excellent information about the Samas ransomware, check out Kevin Strickland's blog post on the topic. Kevin did some really great work, and I really can't say enough great things about the work he did, and what he shared.
Windows Registry
Over on the Follow the White Rabbit blog, @_N4rr34n6_ has an interesting article discussing the Windows Registry. The article addresses setting up and using RegRipper and its various components, as well as other tools such as Corey Harrell's auto_rip and Phill Moore's RegRipper GUI, both of which clearly provide a different workflow placed over the basic code.
Podcasts
I've had the honor and privilege to be asked to be involved on a couple of podcasts recently, and I thought I'd share the links to all of them in one place, for those who are interested in listening:
Doug Brush's CyberSecurity Interviews - I've followed Doug's CyberSecurity Interviews from the beginning, and greatly appreciated his invitation and opportunity to engage
Down the Security Rabbithole with Rafal and James; thanks to both of these fine gentlemen for offering me the opportunity to be part of the work they're doing
Nuix Unscripted - Corey did a really great job moderating Chris and I, which brought things full circle; not only did Chris and I used to work together, but Chris was one of the very first folks interviewed by Doug Brush...
Investigations
Chris Woods over at Nuix (transparency: this is my employer) posted an excellent article regarding three best practices for increasing the efficiency of examinations. Interestingly enough, these are all things that I've endorsed over the years...defining clear analysis goals, collaboration, and using what has been learned from previous investigations. I want to say something about "great minds", but the simple fact is that these are all "best practices" that simply make sense. It's as simple as that.
WifiPasswordReveal
I ran across something really fascinating today..."wait," you ask, "more fascinating than making your computer recite lines from the Deadpool movie??" Well...no...but almost! Here is a fascinating article that illustrates not only the steps for how to reveal Wifi passwords on a Win7+ computer, but provides a batch file for doing so! How cool is that?
LNK Metadata
A bit ago, I'd taken a look at a Windows shortcut/LNK file from a campaign someone had blogged about, and then submitted a Yara rule to detect submissions to VirusTotal, based on the MAC address, volume serial number, and SID embedded in the LNK file. This was based on an LNK file that had been sent to victims as an attachment.
The Yara rule I submitted a while back looks like this:
rule ShellPhish
{
strings:
$birth_node = { 08 D4 0C 47 F8 73 C2 }
$vol_id = { 7E E4 BC 9C }
$sid = "2287413414-4262531481-1086768478" wide ascii
condition:
all of them
}
So, pretty straightforward. The thing is, over the past few days, I've seen a pretty significant up-tick in responses from the retro hunt, indicating a corresponding up-tick in submissions to VT. Up to this point, I'd been seeing maybe one or two detections (again, based on submissions) a week; I've received about a few dozen or so in the past two days alone. This up-tick in responses is an interesting change, particularly because I'm not seeing a corresponding mention of campaigns utilizing LNK files as attachments (to emails, or embedded in documents, etc.).
A couple of things I haven't done is note the first submission dates for the items, as well as the country from which they were submitted, and then downloaded the LNK file itself to parse out the command line, and note the differences.
So, why am I even mentioning this? Well, this goes back to Jesse Kornblum's premise of using every part of the buffalo, albeit the fact that it's not directly associated with memory analysis. The metadata in file formats such as documents and LNK files can be used to develop insight based on relationships, which can lead to attribution based on further developing the threat intelligence you already have available.
Subscribe to:
Posts (Atom)