Digital forensics and incident response (DFIR) has hit a tipping point. No longer just for law enforcement solving cybercrimes, DFIR tools and practices are a necessary component of any organization’s cybersecurity. After all, attacks are increasing daily and getting more sophisticated – exposing millions of people’s personal data, hijacking systems around the world and shutting down numerous sites.
SANS has a smorgasbord of DFIR training, and we also offer a free Linux distribution for DFIR work. Our SANS Investigative Forensic Toolkit (SIFT) Workstation is a powerful collection of tools for examining forensic artifacts related to file system, registry, memory, and network investigations. It is also available bundled as a virtual machine (VM), and includes everything one needs to conduct any in-depth forensic investigation or response investigation.
The SIFT Workstation was developed by an international team of forensics experts, including entrepreneur, consultant and SANS Fellow Rob Lee, and is available to the digital forensics and incident response community as a public service. Just because it’s freely available and originally designed for training, though, doesn’t mean it can’t stand up to field investigations. The SIFT Workstation incorporates powerful, cutting-edge open-source tools that are frequently updated, vetted by the open source community and able to match any modern DFIR tool suite. Don’t just take our word for it. Thousands of individuals download SIFT yearly, and it’s used by tens of thousands of people all over the world, including those at multiple Fortune 500 companies. And recently, HackRead named SIFT Workstation in a list of the top 7 cyber forensic tools preferred by specialists and investigators around the world.
SIFT got its start in 2007, during the time SANS instructors were developing virtual machines (VMs) for use in the classroom. In its earliest iterations, it was available online as a download, but was hard-coded and static so whenever there were updates, users had to download a new version. By 2014, SIFT Workstation could be downloaded as an application series and was later updated to a very robust package based on Ubuntu. It can also be installed on Windows, if there is an Ubuntu subsystem running on the system.
In November 2017, SANS unveiled a new version of SIFT Workstation that allows for much more functionality, is much more stable, and is comprised of specific tools such as the Package Manager. This time the package supports rolling updates, and uses SALT, a Python-based configuration management platform, rather than a bootstrap executable and configuration tool.
The new version can work with more than 200 tools and plug-ins from third-parties, and newly added memory analysis functionality enables the SIFT Workstation to leverage data from other sources. New automation and configuration functions mean the user only has to type one command to download and configure SIFT. Because SIFT is scriptable, users can string together commands and create automated analysis, customizing the system to the needs of their investigation.
Download SIFT Workstation today, and get started on your own DFIR initatives. And look into our FOR508: Advanced Incident Response and Threat Hunting course for hands-on learning with SIFT, and how to detect breaches, identify compromised and affected systems, determine damage, contain incidents, and more.
Many experienced security analysts end up repeating the same investigative playbook for similar types of cases day after day. They become technical experts but siloed into a single lane of investigative scenario, whether it be intellectual property theft, malware or intrusion investigations. With the rapid evolution of fileless malware and sophisticated anti-forensics mechanisms, security analysts need access to current system state that can be derived solely from memory analysis. Learning bleeding edge analysis skills such as memory interrogation can be a touch challenge requiring determined and extraordinary work. The relaunched bootcamp SANS FOR526 Advanced Memory Forensics and Threat Detection is the class that will get you and your team to this next level – it’s time for bootcamp!
Malware is more sophisticated, and its ability to evade detection growing. Cryptojacking – software programs and malware that hijack another’s computer without their knowledge to mine cryptocurrency – is one such example. Recently, researchers discovered a new cryptocurrency mining malware that employs multiple evasion techniques, including one that poses as an installer file for the Windows operating system so it seems less suspicious. And illicit cryptocurrency mining operations have increased dramatically over the past year, according to a recent Cyber Threat Alliance report, rising by as much as 459 percent in 2018.
The more complex, advanced malware and anti-analysis and evasion techniques pose great challenges to today’s security practitioners, as the endpoint detection methods and technologies, we rely upon to protect our enterprise fail. For this reason, we at SANS have decided to go big with a revised FOR526 course – with an additional boot camp – that teaches you how to isolate malicious activity using memory analysis to counter these evasions and allows you to determine the capability and intent of the intrusion for successful scoping and containment.
To move to proactive hunting, teams must have the skills to identify the activity for which there is no signature. The FOR526 course delivers this expertise with an intensive hands-on focus, allowing security practitioners to build on the knowledge advanced security professionals already have.
The two creators of FOR526, Alissa Torres and Jake Williams, understand the unique challenges of memory forensics and the complex types of cases examiners are up against today. Both forensics practitioners themselves, they know examiners need deeper technical expertise beyond just running a tool so they can perform memory analysis to understand the evidence, and that means offering students labs inspired by real-world investigations in which memory forensics saved the day. As Williams notes, “memory offers a very dense and target-rich search space for evidence of value. Memory-only malware? Malicious insiders using private browsing to eliminate disk evidence? Anti-forensics techniques? They all get stuck in memory.”
Williams and Torres have added a boot camp consisting of additional content and memory forensics challenges to make the course even more relevant for present-day memory forensics investigations and threat detection. The NEW FOR526: Advanced Memory Forensics and Threat Detection BootCamp brings you extended mid-week SANS NetWars challenges, more in-depth technical content and advanced threat detection scenarios to take senior incident responder professionals to the next level.
We are excited to announce the release of an all-new version of the free SOF-ELK®, or Security Operation and Forensics ELK virtual machine. Now based on the new version of the Elastic Stack, SOF-ELK is a complete rebuild that is faster and more effortless than its predecessors, making forensic and security data analysis easier than ever.
Since its introduction about five years ago, there have been more than 10,000 downloads of SOF-ELK around the world by computer forensic investigators and information security operations personnel in the government, law enforcement and commercial sectors. The SOF-ELK platform is a customized build of the open source ELK stack, consisting of the Elasticsearch storage and search engine, Logstash ingestion and enrichment component, and the Kibana dashboard frontend.
SOF-ELK was always designed to help minimize the typically long and involved setup process the ELK stack requires by delivering a pre-built virtual appliance that can be downloaded in a ready-to-use state. It can consume various source data types (numerous log types as well as NetFlow), parses out the most critical data fields, and presents it on several stock dashboards. Users can also build custom data visualizations that suit their own investigative or operational requirements (and because of the fully open source nature of the project, can choose to contribute those custom builds back to the primary code repository). Learn more about the SOF-ELK distribution.
The new version of SOF-ELK has been rebuilt from the ground up to take advantage of the new version of the Elastic Stack software and uses all of the Elastic Stack’s components. This required a total rebuild of all dashboards and supporting scripts. Simply download this distribution, turn it on, feed it some data and begin analysis. It’s that easy.
The SANS team has performed extensive testing of this distribution of the SOF-ELK platform. The new version’s most immediate benefits are its speed and refreshed browser interface. This is faster and easier to use and can visualize massive amounts of data through the dashboards. We also expect faster development cycles. Here are some more changes in the new SOF-ELK:
Supports the latest updates on the kernel and all CentOS packages.
Includes new parsers from upstream and community contributions.
Rebuilt and revalidated all Logstash parsers against latest syntax
Better handles dynamic (boot-time) memory allocation for Elasticsearch.
Rebuilt all Kibana dashboards to handle updated index mappings and field names
IPv6 addresses can now be handled as IPs instead of strings
Features many under-the hood changes that will make our roadmap much smoother in the future
The SOF-ELK platform was initially developed for SANS FOR572, Advanced Network Forensics and Analysis, and is now used in SANS SEC555, SIEM with Tactical Analysis. Additional course integrations are being actively worked at this time and considered for future versions. However, SOF-ELK was always designed as a free resource for the digital forensic and broader information security communities at large – a ready-to-use appliance that teams can use without having to invest the many hours into deploying, configuring, and maintaining an Elastic Stack instance. We hope you check out the latest version of the SOF-ELK distribution.SOF-ELK®: A Free, Scalable Analysis Platform for Forensic, incident Response, and Security Operations
There is no shortage of digital evidence, with many DFIR and Security Operations teams handling terabytes of log and network data per week. This amount of data presents unique challenges, and many tools are simply inadequate at such a large scale. Commercial platforms that are up to the task are often far out of budgetary reach for small- and medium-sized organizations.
The Elastic Stack, a big data storage and analysis platform, has become increasingly popular due to its scalability and open-source components. Countless investigative and security teams have incorporated Elastic into their toolkits, often realizing the significant level of effort required to customize and manage such a powerful tool. To overcome some of these hurdles, the SOF-ELK platform was created. SOF-ELK aims to be an appliance-like virtual machine that is preconfigured to ingest and parse several hundred different types of log entries, as well as NetFlow data. The intent is to provide analysts and investigators with a tool that leverages the power of the Elastic Stack with minimal setup time and effort. Originally a part of the SANS FOR572, Advanced Network Forensics & Threat Hunting course, SOF-ELK has been incorporated into additional SANS courses and is released as a free and open-source platform for the overall security community.
In this webcast, we will explore SOF-ELKs use cases, types of log data currently supported, as well as how to load data from live or archived sources. We will also show the various dashboards supplied with the VM and show how new features can be activated through the projects GitHub repository.
You are being exposed to malicious scripts in one form or another every day, whether it be in email, malicious documents, or malicious websites. Many malicious scripts at first glance appear to be impossible to understand. However, with a few tips and some simple utility scripts, you can deobfuscate them in just a few minutes.
SANS Instructor Evan Dygert conducted a webcast on October 3rd, 2018. This webcast teaches you how to cut through the obfuscation techniques the script authors use and not spend a lot of time doing it. Evan also demonstrates how to quickly deobfuscate a variety of malicious scripts.
The samples of the scripts he provided during the webcast can be downloaded here: https://dfir.to/MaliciousScripts. Please note the password for the samples.zip folder is: “infected”
Tips for Reverse-Engineering Malicious Code – This cheat sheet outlines tips for reversing malicious Windows executables via static and dynamic code analysis with the help of a debugger and a disassembler. Download Here
REMnux Usage Tips for Malware Analysis on Linux – This cheat sheet outlines the tools and commands for analyzing malicious software on the REMnux Linux distribution Download Here
Cheat Sheet for Analyzing Malicious Documents – This cheat sheet presents tips for analyzing and reverse-engineering malware. It outlines the steps for performing behavioral and code-level analysis of malicious software. Download Here
Malware Analysis and Reverse-Engineering Cheat Sheet – This cheat sheet outlines tips and tools for analyzing malicious documents, such as Microsoft Office, RTF and Adobe Acrobat (PDF) files Download Here
Microsoft Office Macros have been the bane of security analysts’ lives since the late 1990s. Their flexibility and functionality make them ideal for malware authors to use as a primary stage payload delivery mechanism, and to date the challenge they pose remains unsolved. Many organisations refrain from blocking them completely due to the impact it would cause to their users, and instead rely on a combination of detection and mitigation technology to compensate for the risk they pose.
I have long thought that it would be ideal if Microsoft were able to implement granular controls via group policy over which activities macros were permitted to perform, for example allowing the blocking of process execution or network activity. In the interim, I have been experimenting with alternative methods to limit which functions a macro can call, either by redefining or patching the high risk API calls to prevent their intended outcome.
Below we can see a very basic example of what a malicious macro might look like. The fact that the subroutine is named “AutoOpen” means that it will be run as soon as the document is opened (and if required, macros are enabled). The command “Shell” at the beginning of the line instructs Word to execute the process as specified in the parameter, so in this case the macro will launch the Windows calculator.
Option 1 – Using global templates to override built-in functions
Shell is the function built into VBA which is used to launch new processes, and as such, can often be found in malicious macros. Malware authors leveraging macros as a primary stage payload typically want to either download or drop a file, and then execute it. Alternatively, they could decide to execute an existing process on the system, such as powershell, with parameters which will take actions against their intended target. Common to both of these methods is the requirement for something to be run, and this is where Shell comes in. If we were able to somehow disable the Shell function, then we might be able to prevent the malicious macro from succeeding in it’s goal.
The first experiment involved redefining the Shell function, with the hope that the newly defined function would override the built-in one. We can achieve this by placing the code in the global template which is named normal.dotm or within an add-in (which is effectively a template that is loaded every time Word is opened), either way, our code will become part of the malicious macros execution.
Below we can see the redefined function used as part of this experiment. This was saved within normal.dotm (the global template), with the intention that when Shell was called, rather than calling the system function to launch the process, our redefined function would be called, resulting in a popup warning the user that the activity had been blocked.
Then, using the one line test macro that attempts to execute ‘cmd.exe /c calc.exe’, we can see that the redefined function worked well and blocked the execution of the process. Unfortunately, it only seemed to work when the malicious code was placed within the document and not when it was within a seperate module. The reason for this is unknown and warrants further research, as if solved, this would be the easiest way to achieve our goal.
Option 2 – Patching associated API in VBE7.dll to alter behaviour
For a more surgical approach we can look at API hooking the dll which is leveraged when macro code is executed. Looking through the dlls, which are loaded into Word at runtime, we can observe that VBE7.dll includes a large number of exports that appear related to the execution of macro code. Below we can see a snapshot from the list of exports with one in particular highlighted, rtcShell, that warranted further investigation.
Digging into this function we can see that it’s nothing more than a small wrapper around the CreateProcess Windows API call. The particular code block which executes the process is listed below. Looking at the parameters being passed to the API, we can see that the EBX register is being used to hold a pointer to the name of the process to be executed.
At this point, if we want to alter the way the process is launched we can patch the instructions to alter the process creation flags, which is one of the parameters passed to the CreateProcess API. Alternatively, we could completely patch out the API call to prevent the execution from occurring.
In this case we are going to leverage the CREATE_SUSPENDED process creation flag to allow the process to launch, but immediately be frozen into a suspended state, preventing the code from running.
The patch sets the ECX register to 4, which is the numeric value of CREATE_SUSPENDED, and then this is pushed as the creation flags parameter to the CreateProcess API call, resulting in the process being instructed to launch in a suspended state.
Following this patch, a test macro that was designed to launch powershell was executed, and as we can see from the process explorer window, it was placed into a suspended state, thus mitigating any impact and allowing an opportunity for endpoint protection sensors to scan and identify any threatening behaviour.
These are just proof of concepts, and would require more research and work before they were used in a production environment. I still believe that the ideal state would be for Microsoft to implement more granular security controls against macros, allowing organisations to continue using them, but at the same time empowering them with the ability to limit their capabilities depending on individual risk appetites.
The SANS DFIR Summit and Training 2018 is turning 11! The 2018 event marks 11 years since SANS started what is today the digital forensics and incident response event of the year, attended by forensicators time after time. Join us and enjoy the latest in-depth presentations from influential DFIR experts and the opportunity to take an array of hands-on SANS DFIR courses. You can also earn CPE credits and get the opportunity to win coveted DFIR course coins!
To commemorate the 11th annual DFIR Summit and Training 2018, here are 11 reasons why you should NOT miss the Summit this year:
1. Save money! There are two ways to save on your DFIR Summit & Training registration (offers cannot be combined):
· Register for a DFIR course by May 7 and get 50% off a Summit seat (discount automatically applied at registration), or
· Pay by April 19 and save $400 on any 4-day or 6-day course, or up to $200 off of the Summit. Enter code “EarlyBird18” when registering.
· The two-day Summit will kick off with a keynote presentation by Kim Zetter, an award-winning journalist who has provided the industry with the most in-depth and important investigative reporting on information security topics. Her research on such topical issues as Stuxnet and election security has brought critical technical issues to the public in a way that clearly shows why we must continue to push the security industry forward.
· The Summit agenda will also include a presentation about the Shadow Brokers, the group that allegedly leaked National Security Agency cyber tools, leading to some of the most significant cybersecurity incidents of 2017. Jake Williams and Matt Suiche, who were among those targeted by the Shadow Brokers, will cover the history of the group and the implications of its actions.
· All DFIR Summit speakers are industry experts who practice digital forensics, incident response, and threat hunting in their daily jobs. The Summit Advisory Board handpicked these professionals to provide you with highly technical presentations that will give you a brand-new perspective of how the industry is evolving to fight against even the toughest of adversaries. But don’t take our word for it, have a sneak peek, check out some of the past DFIR Summit talks.
Immerse yourself in six days of the best in SANS DFIR training. Here are the courses you can choose from:
3. All courses will be taught by SANS’s best DFIR instructors. Stay tuned for more information on the courses we’re offering at the conference in a future article post.
4. Rub elbows and network with DFIR pros at evening events, including networking gatherings and receptions. On the first night of the Summit, we’re going to gather at one of Austin’s newest entertainment venues, SPiN, a ping pong restaurant and bar featuring 14 ping pong tables, lounges, great food, and drinks. Give your overloaded brain a break after class and join us at our SANS Community Night, Monday, June 9 at Speakeasy. We will have plenty of snacks and drinks to give you the opportunity to network with fellow students.
5. Staying to take a DFIR course after the two-day Summit? Attend SANS@Night talks guaranteed to enrich your DFIR training experience with us. Want to know about threat detection on the cheap and other topics? As for cheap (and in this case, that doesn’t mean weak), there are actions you can take now to make threat detection more effective without breaking the bank. Attend this SANS@Night talk on Sunday evening to learn some baselines you should be measuring against and how to gain visibility into high-value actionable events that occur on your systems and networks.
6. Celebrate this year’s Ken Johnson Scholarship Recipient, who will be announced at the Summit. This scholarship was created by the SANS Institute and KPMG LLP in honor of Ken Johnson, who passed away in 2016. Early in Ken’s digital forensics career, he submitted to a Call for Presentations and was accepted to present his findings at the 2012 SANS DFIR Summit. His networking at the Summit led to his job with KPMG.
7. Prove you’ve mastered the DFIR arts by playing in the DFIR NetWars – Coin Slayer Tournament. Created by popular demand, this tournament will give you the chance to leave Austin with a motherlode of DFIR coinage! To win the new course coins, you must answer all questions correctly from all four levels of one or more of the six DFIR Domains: Windows Forensics & Incident Response, Smartphone Analysis, Mac Forensics, Memory Forensics, Advanced Network Forensics, and Malware Analysis. Take your pick or win them all!
8. Enjoy updated DFIR NetWars levels with new challenges. See them first at the Summit! But not to worry, you will have the opportunity to train before the tournament. You’ll have access to a lot of updated posters that can serve as cheat sheets to help you conquer the new challenges, as well as the famous SIFT WorkStation that will arm you with the most powerful DFIR open-source tools available. You could also choose to do an hour of crash training on how to use some of our Summit sponsors’ tools prior to the tournament. That should help give you an edge, right? That new DFIR NetWars coin is as good as won!
9. The Forensic 4:cast Awards winners will be announced at the Summit. Help us celebrate the achievements of digital forensic investigators around the world deemed worthy of the award by their peers. There is still time to cast your vote. (You may only submit one set of votes; any additional voting will be discounted). Voting will close at the end of the day on May 25, 2018.
10. Come see the latest in tools offered by DFIR solution providers. Summit sponsors and exhibitors will showcase everything from managed services covering advanced threat detection, proactive threat hunting, and accredited incident response to tools that deliver rapid threat detection at scale, and reports that provide insights for identifying potential threats before they cause damage.
11. Last but not least, who doesn’t want to go to Austin?!? When you think Austin, you think BBQ, right? This city isn’t just BBQ, Austin has amazing food everywhere and there’s no place like it when it comes to having a great time. The nightlife and music include the famous 6th Street – which, by the way, is just walking distance from the Summit venue. There are many other landmarks such as Red River, the Warehouse District, Downtown, and the Market District. You will find entertainment of all kinds no matter what you’re up for. Nothing wrong with some well-deserved play after days full of DFIR training, lectures, and networking!
As you can see, this is an event you do not want to miss! The SANS DFIR Summit and Training 2018 will be held at the Hilton Austin. The event features two days of in-depth digital forensics and incident response talks, nine SANS DFIR courses, two nights of DFIR NetWars, evening events, and SANS@Night talks.
The Summit will be held on June 7-8, and the training courses run from June 9-14.
MELTDOWN SPECTRE VULNERABILITIES
Unless you’ve been living under a rock for the last 24 hours, you’ve heard about the Meltdown and Spectre vulnerabilities. I did a webcast with SANS about these vulnerabilities, how they work, and some thoughts on mitigation. I highly recommend that you watch the webcast and/or download the slides to understand more of the technical details. In this blog post, I would like to leave the technology behind and talk about action plans. Our goal is to keep this hyperbole free and just talk about actionable steps to take moving forward. Action talks, hyperbole walks.
To that end, I introduce you to the “six step action plan for dealing with Meltdown and Spectre.”
Step up your monitoring plan
Reconsider cohabitation of data with different protection requirements
Review your change management procedures
Examine procurement and refresh intervals
Evaluate the security of your hosted applications
Have an executive communications plan
Step 1: Step up your monitoring plan
Meltdown allows attackers to elevate privileges on unpatched systems. This means that attackers who have a toehold in your network can elevate to a privileged user account on a system. From there, they could install backdoor and rootkits or take other anti-forensic measures. But at the end of the day, the vulnerability doesn’t exfiltrate data from your network or encrypt your data, delete your backups, or extort a ransom. Vulnerabilities like Meltdown will enable attackers, but they are only a means to an end. Solid monitoring practices will catch attackers whether they use an 0-day or a misconfiguration to compromise your systems. As a wise man once told me, “if you can’t find an attacker who exploits you with an 0-day, you need to be worried about more than 0-days.”
Simply put, monitor like your network is already compromised. Keeping attackers out is so 1990. Today, we assume compromise and architect our monitoring systems to detect badness. The #1 goal of any monitoring program in 2018 must be to minimize attacker dwell time in the network.
Step 2. Reconsider cohabitation of data with different protection requirements
Don’t assume OS controls are sufficient to separate data with different protection requirements. The Spectre paper introduces a number of other possible avenues for exploitation. The smart money says that at least some of those will be exploited eventually. Even if other exploitable CPU vulnerabilities are not discovered (unlikely since this was already an area of active research before these vulnerabilities), future OS privilege escalation vulnerabilities are a near certainty.
Reconsider your architecture and examine how effective your security is if an attacker (or insider) with unprivileged access can elevate to a privileged account. In particular, I worry about those systems that give a large number of semi-trusted insiders shell access to a system. Research hospitals are notorious for this. Other organizations with Linux mail servers have configured the servers so that everyone with an email address has a shell account. Obviously this is far from ideal, but when combined with a privilege escalation vulnerability the results can be catastrophic.
Take some time to determine if your security models collapse when a privilege escalation vulnerability becomes public. At Rendition, we’re still running into systems that we can exploit with DirtyCOW – Meltdown isn’t going away any time soon. While you’re thinking about your security model, ask how you would detect illicit use of a privileged account (see step #1).
Step 3. Review your change management procedures
Every time there’s a “big one” people worry about getting patches out. But this month Microsoft is patching several critical vulnerabilities. Some of these might be easier to exploit than Meltdown. When thinking about patches, measure your response time. We advise clients to keep three metrics/goals in mind:
Normal patch Tuesday
Patch Tuesday with “active exploit in the wild”
“Out of cycle” patch
How you handle regular patches probably says more about your organization than how you handle out of cycle patches. But considering all three events (and having different targets for response) is wise.
Because of performance impacts, Meltdown definitely should be patched in a test environment first. Antivirus software has reportedly caused problems (BSOD) with the Windows patches for Spectre and Meltdown as well. This shows a definite example where “throw caution to the wind and patch now” is not advisable. Think about your test cycles for patches and figure out how long is “long enough” to test (both for performance and stability) in your test environment before pushing patches to production.
Step 4. Examine procurement and refresh intervals
There is little doubt that future processors (yet to be released) will handle some functions more securely than today’s models. If you’re currently on a 5 year IT refresh cycle, should you compress that cycle? It’s probably early to tell for hardware, but there are a number of older operating systems that will never receive patches. You definitely need to re-evaluate whether leaving those unpatchable systems in place is wise. Just because you performed a risk assessment in the past, you don’t get a pass on this. You have new information today that likely wasn’t available when you completed your last risk assessment. Make sure your choices still make sense in light of Meltdown and Spectre.
When budgeting for any IT refresh, don’t forget about the costs to secure that newly deployed hardware. Every time a server is rebuilt, an application is installed, etc. there is some error/misconfiguration rate (hopefully small, often very large). Some of these misconfigurations are critical in nature and can be remotely exploited. Ensure that you budget for security review and penetration testing of newly deployed/redeployed assets. Once the assets are in production, ensure that they are monitored to detect anything that configuration review may have missed (see step #1).
Step 5. Evaluate the security of your hosted applications
You can delegate control, but you can’t delegate responsibility. Particularly when it comes to hosted applications, cloud servers, and Platform as a Service (PaaS), ask some hard questions of your infrastructure providers. Sure your patching plan is awesome and went off without a hitch (see step #3). What about your PaaS provider? How about your IaaS (Infrastructure as a Service) provider? Ask your infrastructure provider:
Did they know about the embargoed vulnerability?
If so, what did they do to address the issue ahead of patches being available?
Have they patched now?
If not, when will they be fully patched?
What steps are they taking to look for active exploitation of Meltdown? *
* #5 is sort of a trick question, but see what they tell you…
Putting an application, server, or database in the cloud doesn’t make it “someone else’s problem.” It’s still your problem, it’s just off-prem. At Rendition, we’ve put out quite a few calls today to MSPs we work with. Some of them have been awesome – they’ve got an action plan to finish patching quickly and monitoring for all assets. One called us last night for advice, another called us this morning. Others responded with “Melt-what?” leading us to wonder what was going on there. Not all hosting providers are created equal. Even if you evaluated your hosting provider for security before you trusted them with your data, now is a great time to reassess your happiness with how they are handling your security. It is your security after all…
Step 6. Have an executive communications plan
When any new vulnerability of this magnitude is disclosed, you will inevitably field questions from management about the scope and the impact. That’s just a fact of life. You need to be ready to communicate with management. To that end, in the early hours of any of these events there’s a lot of misinformation out there. Other sources of information aren’t wrong, they’re just not on point. Diving into the register specific implementations of a given attack won’t help explain the business impact to an executive.
Spend some time today and select some sources you’ll turn to for information the next time this happens (this won’t be the last time). I’m obviously biased towards SANS, but I wouldn’t be there if they didn’t do great work cutting through the FUD (fear uncertainty and doubt) when it matters. The webcast today was written by me, but reviewed by other (some less technical) experts to make sure that it was useful to a broad audience. My #1 goal was to deliver actionable information you could use to educate a wide range of audiences. I think I hit that mark. I’ve seen other information sources today that missed that mark completely. Some were overly technical, others were completely lacking in actionable information.
Once you evaluate your data sources for the next “big one,” walk through a couple of exercises with smaller vulnerabilities/issues to draft communications to executives and senior leadership. Don’t learn how to “communicate effectively” under the pressure of a “big one.” Your experience will likely be anything but “effective.”
Take some time today to consider your security requirements. It’s a new year and we certainly have new challenges to go with it. Even if you feel like you dodged this bullet, spend some time today thinking about how your organization will handle the next “big one.” I think we all know it’s not a matter of “if” but a matter of “when and how bad.”
Of course, if I don’t tell you to consider Rendition for your cyber security needs, my marketing guy is going to slap me silly tomorrow. So Dave, rest easy my friend. I’ve got it covered
Software that automatically updates itself presents an attack surface, which can be leveraged en masse through the compromise of the vendor’s infrastructure. This has been seen multiple times during 2017, with high profile examples including NotPetya and CCleaner.
Most large organisations have built robust perimeter defences for incoming and outgoing traffic, but this threat vector is slightly different and far more difficult to detect. Update packages are often deployed in compressed, encrypted or proprietary formats and would not easily be subject to an antivirus scan or sandbox analysis during transit. This leaves us with a large number of trusted processes within our infrastructure that could turn on us at any time and download something evil, which could potentially be undetectable by endpoint antivirus software.
It would be almost impossible to detect all potential malicious code changes, as they could be as simple as changing a single assembly instruction from JNZ to JZ to allow for unauthorised access or privilege escalation to occur. However, this doesn’t prevent some additional proportionate due diligence on the update package being pulled down and installed.
Methodology for discovering inbound evil updates
1. Discover all the software across your estate that could be auto updating
Let us consider for a moment software that automatically updates, and how it looks on the endpoint. Firstly, it needs to open an internet connection to a server that will allow it to identify whether the version currently running is up to date, or whether there is a newer version available. This may occur when the process is first executed or at intervals (set dates or times or even randomly). If the version is current then it will try again later, mostly likely connecting to the same server and repeating the process of checking the version numbers. The traffic volume on each occasion is likely to be very small, after all, all that it needs to ask is “what is the current version number?” and the reply need only be “1.0.32” or similar.
If we put these components together we can build a search for a process, other than a browser (to reduce the noise), which makes repetitive connections to the same server on multiple occasions. We can further refine by looking for low volume traffic in the transmissions. This data may contain false positives such as the checking of licence validation, however this doesn’t matter as we will refine this further in the next stages. 2. Monitor traffic ratios for evidence of updates being downloaded
Once we have a list of processes, devices and servers that have displayed the behaviour from our discovery phase, we can now monitor the traffic volume ratios for abnormal behaviour. Consider a process that had been polling the same server with 5KB uploads followed by 50KB downloads for the past month when suddenly the volume of the download changes to 300MB. It would be a clear outlier based on volumes and upload/download ratios. 3. Perform automated sandbox analysis on detected binaries post update
Now we’re looking for a suspicious update, not just any update, so we can send the installer from the endpoint to an internal sandbox for analysis. Alternatively, we could trigger the same update to occur within a sandbox running our gold image. The sandbox would perform a behavioural analysis, which we would use to highlight any suspicious behaviour during, or after the update process takes place. 4. Alert CERT for further examination should there be evidence of anything suspicious
This can then feed the alerting system used by our SOC/CERT for a manual review and prompt containment activity should the updates contain malware – at this point the number of machines that have pulled the update should be small and we can prevent further infections through proxy blocks etc.
Demonstration of concept
Here we will demonstrate the concept by conducting a deep dive into the behavior of the Notepad++ update process. We begin by identifying the polling between the process and update server. We can see from Process Monitor below that the traffic volumes are low, and the upload / download ratio is relatively similar, approximately 1:11 when there is no update to be downloaded.
Now let’s have a look at what happens when there is an update available.
We can see the difference when there is an update to be pulled, in this case the download volume is significantly higher than the upload as we would expect, in fact it’s over 673 times higher at 1:7756.
In addition, following the network activity we can see that a process launch has been identified. This is the start of the update installation and provides us details on the location of the update binary. At this point we can take the desired action to review the file, this may include a local scan or better yet, uploading the binary to an internal sandbox for behavioural analysis to take place – this would give us the added benefit of detecting a threat before the antivirus signatures are available.
Practicalities and further ideas
In a large network there is going to be a lot of noise and you may want to select the top 50 auto updating processes that are most widely utilised across the estate and focus on them. This way you can be more selective about the alerts that go to your SOC.
Some processes may update on the fly using hot patching, in which case better results would be obtained from the creation of a custom image for your sandbox with all of these processes installed, so there would be no need to send/pull binaries and you could monitor the entirety of the update process taking place, including all files dropped to disk and executed during the update.
Malware authors are frequently observed leveraging server side scripting on their infrastructure to evade detection and better target their attacks. This includes both exploit kits and servers hosting secondary stage payloads, all of which can easily be set up to alter their responses based on the footprint of the visitor. This could include geolocation of the IP address visiting the site if the attacker is targeting users from a particular country or region, or perhaps user-agent if they are only focused on certain browsers or operating systems. Without access to the source code leveraged on the server, it is difficult to detect whether it would alter its behaviour if you were visiting from a different device or location, and therefore malware analysts may find themselves declaring a link benign, or that the payload server is down, when in fact, it is only presenting that way to the analyst in question.
Got an example?
An example of this can be seen in the Malwarebytes blog on Magnitude exploit kit which details that “…users are inspected at a ‘gate’ that decides whether or not they should be allowed to proceed to Magnitude EK. This gate, which has been nicknamed ‘Magnigate’ by Proofpoint, performs additional checks on the visitor’s IP address and user-agent to determine their geolocation, Internet Service Provider, Operating System and browser information…”
Hmm, so what can I do?
There is of course a balance here, even if you have access to VPN software, which allows you to select the country you want to appear from, it would be extremely time consuming and cumbersome to iterate through all of the available countries, each time using different browsers and painstakingly looking to identify whether there was any variation in the responses.
To aid in this task, I have written a new tool which automates this whole process and may be useful during malware analysis if you suspect the server is hiding something from you.
It works as follows –
Loads a list of countries and user-agents that you want to appear from
Leverages a proxy listing website’s API to obtain various country proxies
Verifies that the proxies are working, and that the geolocation is per requirements
Connects to the server using the proxy and iterates through all of the user-agents requesting the site multiple times
Identifies any results which are different from the control value and highlights to the analyst
I’ve uploaded a number of test documents to my webserver, which you are welcome to use for your testing:
Both of these do the same thing – they wait until they observe someone connecting from a Chinese IP address with an iPhone user-agent before presenting the main content. The first URL will return a result in all other circumstances stating “Go away”, and the second will return a 404 error unless the conditions are met.
The screenshot below shows the script iterating through various user-agents whilst connected to a Chinese proxy. In each case we can see the result was a 404 until the iPhone user-agent was sent, after which the script presented a ‘diff’ style output on what was different about this case.
Great! Where can I get it?
The script was written in Python (v3.x) and is available from Github here.
Please feel free to use / fork / enhance / provide feedback.
Hundreds of SANS Institute digital forensics students have stepped up to the challenge and conquered. They’ve mastered the concepts and skills, beat out their classmates, and proven their prowess. These are the elite, the recipients of the SANS Lethal Forensicator Coin, an award given to a select portion of the thousands of students that have taken any of the SANS Institute Digital Forensics or Incident Response (DFIR) courses. Now, the institute is expanding the opportunity for students to earn these highly coveted tokens in each of the SANS DFIR courses.
Thanks to an effort led by curriculum lead Rob Lee & the SANS DFIR faculty, students can now win specific SANS Lethal Forensicator Coins designed to go with each of the DFIR course themes. These coins are tailored to be icons and the precious prizes to be won by students as a proof and symbol of their mastery in a specific digital forensics specialty.
“Ex Umbra in Solem”: From the Shadows into the Light In today’s digital world, forensics plays a critical role in uncovering the truth. Forensic examiners shine light on the facts of the case, making good decisions possible. And the forces of evil unceasingly develop new ways to hide their activities, forcing us to continually improve our skills to counter them.
“Non Potestis Celare”: You cannot hide
The most successful incident response teams are evolving rapidly due to near-daily interaction with adversaries. New tools and techniques are being developed, providing better visibility and making the network more defensible. Adversaries can no longer hide.
Today, attackers are modifying their malware with increasing frequency to bypass antivirus and other endpoint controls. Through reverse-engineering Malware (R.E.M) Analysis Masters can isolate the most appropriate Indicators of Compromise (IOCs) to stop & identify malware.
FOR585: Advanced Smartphone Forensics
“Omnis Tactus Vestigium Relinquit”: Every contact leaves a trace Knowing how to recover all of the data residing on the smartphone is now an expectation in the digital forensics field, and examiners must understand the fundamentals of smartphone handling, data recovery, accessing locked devices, and manually recovering data hiding in the background on the device. There are traces of evidence hiding on the device, and you know how to uncover them.
“Malum Loquitur, Bonum Auscultat”: Evil must talk, so good must listen
Network Forensic professionals are hunters with great visibility, who can find a target among a mass of camouflaging data. Wisdom, experience, and stealth are all embodied by the owl’s watchful, unwavering eye, seeking its prey under the cover of darkness. No matter how crafty an adversary may be, their communications will allow the hunter to find, identify, and ultimately eliminate their presence.
“Impera magis. Aliter cogita”: Command more and think differently.
Apple users have always thought differently and that goes for Apple forensicators too. The analysts who hold this coin take command of their forensic analysis and appreciate looking at the raw data and interpreting it correctly without the necessity of superfluous tools. Knowing where you came from can help you move forward, this is where the hat tip to the original colored Apple logo comes in. New artifacts are presented to analysts in every OS update, the knowledge of historic elements may provide insight.
“Hominem unius libri timeo”: I fear the man of one book.
FOR578 is all about developing analytical skills. To think critically and expand our views which is a skill that applies to any security profession. The quote is attributed to Thomas Aquinas and despite the common use of the phrase (which is meant to deride the person who is not well studied across multiple subjects) the original meaning was to state that a person who understood one good book well could defeat their opponent. Thus, this phrase can be interpreted two entirely different ways. Both are about self-education and broadening our views on the world.
Memory forensics reveals deeper insights into the state of a compromised system and stands as the best source for detection of malware and OS/process manipulation/subversion. These analysis methods reveal key evidence which may not be uncovered through querying the operating system or digging through network packets. This quote comes from the original Matrix movie, a question Neo asks of Morpheus when he first wakes from his life in the artificial reality created by sentient machines. It is this awakening and raw view of reality that we as forensic examiners/incident responders strive to achieve through deeper analysis of system memory.
Staying up-to-date with the latest challenges in the digital forensics field demand analytical skills that cannot be gained by just reading a textbook. Just like firemen could never learn the skills of how to fight a fire by just studying theory, incident responders, threat hunters, and digital forensic investigators can test their skills with DFIR Netwars.
New DFIR Challenge coin back design:
The challenges for each course are held on the last day. Students must successfully overcome a number of obstacles, directly compete against fellow students, and prove their proficiency during timed, hands-on incidents. The obstacles, competitions and hands-on scenarios have been created by SANS’ top instructors – digital forensics practitioners, subject matter experts, experienced teachers and professional leaders in their own right. At the end of the challenge, the instructor announces the winner(s) who are awarded the coins at the end of the 6th day of class and winners are later on listed on the SANS Institute’s virtual wall of Lethal Forensicator Coin Holders.
History of the SANS Challenge coins:
The coin – more precisely, Round Metal Object (RMO) – was initially created to recognize students who demonstrate exceptional talent, contributions, or who serve as leaders in the digital forensics profession and community. The coin is meant to be an honor; it is also intended to be rare. SANS Institute uses the coins to identify and honor those who excel at detecting and eradicating threats, understand the critical importance of cybersecurity and continually strive to further not only their knowledge but also the knowledge of the entire digital forensics field. They actively share their experience and encourage learning through participation in the community and are typically leaders in the digital forensics and incident response community.
Those who are awarded the Lethal Forensicator are also bestowed special privileges and recognition, including participation in the so-called and well-regarded “coin check” challenge and response.
“Coin check” Challenge:
Initiated by one coin holder to another, a coin check typically begins by a challenger holding his or her coin in the air or slamming it on a table and yelling “coin check!” All who are challenged must respond by showing their coins to the challenger within 10 seconds, and whoever fails to do so must buy everyone a round of drinks. If all the challenged coin holders do produce their coin, the challenger must by the round of drinks. (By the way, if you accidentally drop your coin and it makes an audible sound on impact, then you’ve “accidentally” initiated a coin check. And, there are no exceptions to the rules!)
Coin checks aside, there are other ways to win the DFIR Challenge coins besides being an exceptional DFIR student and winning the classroom challenges. Each GOLD GCFA, GREM, GCFE member that has written a published white paper that has furthered the field of research in the Digital Forensics field receives a coin, as do SANS Digital Forensics Blog authors who have written six published entries over a one-year span. In addition, speakers and panelists who participate at a SANS Digital Forensic Summit are awarded coins (vendors and vendor-related speakers are not eligible). Finally, any coin holder can nominate an individual in the digital forensics field who has contributed knowledge, tools or service.