Forensic Blogs

An aggregator for digital forensics blogs

by

Update: 1768.py Version 0.0.7

There are no code changes to this version of 1768.py, my tool to analyze Cobalt Strike beacons.

What is new, is file 1768.json: this file contains statistical data for license IDs.

Over a period of one month, I collected license ID information from these sources: threatviewio and @cobaltstrikebot.

For each license ID that is found on more than one IP address / hostname, I include simple statistics: the number of unique IP addresses / hostnames and the number of unique public keys.

When analyzing malicious Cobalt Strike beacons, I often see recurring license IDs. That’s why I decided to add logic and a JSON file to my tool, with license IDs I’ve seen before. And now this has evolved to a small repository of often seen license IDs.

Here is an example with a sample we discussed on the Internet Storm Center diary:

The license ID is 1873433027 and this ID is associated with 18 unique IP addresses / hostnames, and 15 unique public keys. This is a clear indication that this license ID is used by malicious actors. License IDs that have been seen only once, could belong to red teams, that is why they are not included in file 1768.json. The more often a license ID is seen, the higher the chance it is used by malicious actors. Of course, it is not excluded that there are legitimate license IDs from red teams in this list, but I expect they will have low frequencies.

Takeaway: if your sample has a license ID that appears in 1768.json, then it has been seen before (at least twice), and you’re likely not dealing with a pentest.

1768_v0_0_7.zip (https)
MD5: D93AC5707FD0B5315A1225121071C7F2
SHA256: B417790451681643B2269AC516A99F3CEE9F7F374AB529FD53D5702A70F79409

by

DFIR: A New Scope

As we reach the end of the third week of our internship in the Munich Cyber Security Program (led by ComCode), we have continued to research the best tools and practices available to help tackle the problem of doing forensics analysis on terabytes worth of data. Due to the lack of complete and publicly available research into big data forensics, we have conducted extensive research into the more broad categories of digital forensics in the hopes to find tools and techniques that may already exist without the “Big Data” label. Categories such as image forensics, malware forensics, threat intelligence, open-source intelligence, IOC/threat hunting, and more were included in our goal to help find or create a solution. As imagined, this ended up being an overwhelming amount of information. The scope was constantly shifting as new things were discovered, ruled out due to time restraints, or were decided to be too broad to be worth pursuing.

Research has been equally divided between the two of us based upon areas of strength (Ian taking care of Malware Analysis and Threat Intelligence, while Kaya handled Hard Drive/RAM Imaging and Artifact Analysis/Management). This has kept us from going off the deep end with niche research we were largely unfamiliar with. It has also allowed for shared reports to be quickly thrown together, reworked into different formats, and delivered in a legible format. The research has ranged from the broad overview of our preferred topics to the minute details of possible tools and duties which are necessary for that particular area of forensic analysis. This has allowed us to easily switch gears into our new project goal; a comprehensive to-do guide for forensic analysts dealing with a Big Data incident.  

The original plan for this summer was to find a working solution for big data in incident response. Daunting from the beginning, it was decided this past week that the best course of action wouldn’t be to “solve” this, but rather to make a to-do guide for incident response analysts when they walk into a case. A rough draft in progress, we have started outlining best practices, known tools, and methodologies, as well as considerations one has to take while handling an incident. Even without the change in the final product, there have been numerous challenges to our research; the biggest being that both of us come from a more criminal law-related forensic background, while this project requires us to think from a true (network) incident response background. We are working on changing the way we think and view things while adapting to a finalized project end goal that originally wasn’t in the cards. What we got out of this week is that you have to be flexible and be able to shake things off as they happen, because in a field as volatile as this, what you read last week is probably already obsolete or proven otherwise.

Follow us for more updates on this project!

For further questions about Munich Cyber Security Program, or this project please feel free to contact mcsp@comcode.de

-Written by Kaya Overholtzer ‘22 //Digital Forensics & Cybersecurity & Ian Eubanks '21 // Computer & Digital Forensics

The post DFIR: A New Scope appeared first on The Leahy Center for Digital Forensics & Cybersecurity.

by

Frameworks Of Medical Device Security

The field of Medical Device Cybersecurity as I have explored over the last week is a field that is attempting to protect the health of people while walking a line of efficiency vs. security that allows the device to not only be secure but to also be effective in treating the patients who need them. They tow this line by implementing security measures from development until the end of the life cycle discussed last week. These measures come from frameworks released by organizations such as ISO and the IMDRF.

The IMDRF (International Medical Device Regulators Forum) has in recent years put out several guidelines that seek to help address the threats that medical devices can face throughout their lifecycle. These include the “Principles and Practices for Medical Device Cybersecurity “, “Software as a Medical Device”, and “Possible Framework for Risk Categorization and Corresponding Considerations”. These frameworks address best practices in medical devices throughout the lifecycle of the device and even after the device has been introduced to the market. One method that it recommends is to pursue a model of security by design. This is when a company keeps the security of the device, both physical and digital, in mind from the moment they are designed. Keeping in mind any possible risks to the device that might exist in the field and might arise through normal use of the device. This concept of addressing risks is a recurring theme for the security of medical devices. The IMDRF recommends that all medical device manufacturers and designers pursue a risk-based development and assessment model. The risk-based model is one where risks to devices are categorized by severity, assessed to how relevant they are to the device, and then appropriate measures are taken to bring the risk down to acceptable levels without impacting the performance and functionality of the device. The IMDRF also recommends that manufacturers have a robust post-market Incident response plan to allow for the gathering of details on what happened, what changes need to be made, and for updates to be sent out as needed for new threats. This organization is cited heavily in the EU’s 2017 regulation that has come into effect recently known as MDR, which requires in Annex 1 this risk-based model, threat assessment, and security vs. Performance mindset. It is also heavily referenced in the FDA’s current pre and post-market guidelines directly where again the maintenance of a risk framework, secure design, and threat assessment is required.

Another framework that is leveraged by both the FDA and the EU’s MDR is the ISO framework. ISO stands for the International Organization for Standardization and it publishes standards that are used in several industries, however, I focused only on those relating to medical devices, mainly ISO 27001. This framework is also referenced in MDR and the FDA pre and post-market guidelines. This framework makes some important recommendations such as ensuring that in a medical device organization the security is well planned out and documented, ranging from leadership ensuring that everyone who is working on the device is recording and getting the needed security resources, to ensuring that a plan is adaptable to problems that occur so a device can not get bogged down by problems. ISO also recommends that to be compliant an organization needs to maintain an actively adapting threat model for the devices and software they release to proactively protect users. This is a big part of it and will need to be explored in the future.

This week the main issue that I found was finding how these frameworks are applied in regulations as there are guidelines. Due to the constantly evolving nature of the cyber landscape, they have to be relatively open-ended to maintain relevance in such a constantly changing landscape. Therefore defining terms such as “state of the art” and “dynamic risk” is an important hurdle I had to face that I am still actively working to clarify more. 

Follow us for more updates on this project!

For further questions about Munich Cyber Security Program, or this project please feel free to contact mcsp@comcode.de

Written By: Michael Verdi '22 // Computer & Information Systems Security

The post Frameworks Of Medical Device Security appeared first on The Leahy Center for Digital Forensics & Cybersecurity.