Collections methodology
Updated December 23rd, 2021
SecurityScorecard’s collection methodologies include data retrieved from passive sensors, industry partners, private and open source intelligence (OSINT). Our approach is multi-source and also combines multiple publicly-available sets of data. This data is then verified, enriched and compared holistically against six years of historical, confirmed data that is associated with known advanced persistent threat (APT) actors.
The goal of this methodology is not to provide definitive attribution, but to identify medium- to high-confidence connections to well known APT threat actors. Here, we observed multiple connections to state actors, including many well-known Russian APTs. This intelligence analysis is preliminary and we will be releasing a full report of our findings. Further, it is not surprising that APTs are taking advantage of Log4j, given the ubiquity of Log4j in software used across the globe, and industry leaders, who observed similar connections.
Open-source Intelligence Analysis methodology
SecurityScorecard adapted intelligence community, combined with closed source and OSINT data, to build a dynamic visual database of state-sponsored threat actors, cyber criminal actors, and known cybersecurity vulnerabilities. SecurityScorecard utilizes IBM I2 Analyst Notebook (ANB) as a visualization and comparison tool. ANB does not allow duplicate items; which means you cannot have any identical indicators of compromise. Through this methodology, we can see connections between threat networks, victims, and APTs both current and historical. SecurityScorecard then rates these aforementioned connections with confidence statements, including high confidence, medium confidence, low confidence, and no confidence.
After SecurityScorecard collects data from multiple sources–including open sources like OTX, GitHub, Sans, social media, and also private sources, leveraging our global sensor network–we conduct an enrichment process. Enrichment adds context to indicators of compromise. For example, IP addresses have ASN, AS-Owner, Country, etc. data associated with them, and other data, including what domains, domain siblings, or hosts are attributed with them. Connecting these data points to the initial domain provides deeper context to the data we collect and allows for contextualized analysis.
SecurityScorecard performs enrichment on all collected IOCs from all sources utilizing multiple well known IOC collections. Once enriched, SecurityScorecard builds an ANB chart that visualizes the data. Over time, SecurityScorecard combines the ANB charts together based on country of origin which is called a master merge.
There’s little question that you’ve already heard about the recently discovered security flaw related to Log4j, a widely used Java library for logging error messages in applications. The vulnerability enables a threat actor to remotely execute commands via remote code execution (RCE) on nearly any machine using Log4j. But it’s also important to cut through all of the noise to truly understand the implications of the Log4j and what organizations can do to combat it.
What SecurityScorecard is doing
To that end, the SecurityScorecard Global Investigations team has utilized its global scanning technology to research and understand the mechanics of the Log4j security flaw. We’re then sharing insights gleaned from that research to help enterprises better understand this security issue and actions they can take to mitigate it.
To that end, our research has revealed two key findings that shed more light on Log4j:
1. Through our telemetry, SecurityScorecard observed active exploitation in the wild from threat actors using infrastructure in China and Russia (Figure 1). Additionally, we observed reconnaissance originating from multiple countries – activity is intended to identify targets that might be vulnerable. The most frequent exploitation attempts occurred from China, followed by Russia.
2. SecurityScorecard analysts discovered connections to APT10, including three SHA256s to IP addresses. These types of connections are considered high confidence. A connection between SHA256 and an IP is likely present because the malware is embedded into the IP and vice versa. By comparing Log4j telemetry and other intelligence from OSINT and private sources to the Russian APT data collection, nine direct connections to Russian APTs and 500+ secondary connections to Russian APTs were discovered (Figure 2). The connections to Russian APTs include multiple groups. Eight of the nine connections are SHA256s.
What actions should you take?
Ultimately, what the Log4j vulnerability reveals is that nation state adversaries are jumping into the game and attacking different organizations through this vulnerability. As such, enterprises should take a number of steps to protect their resources:
- Update the version of Log4j to the most recent version. Currently, that’s Log4j 2.17.0. But it’s important to regularly check back and update new versions as they’re added.
- Monitor the network for suspicious activity. There’s no question that threat actors aren’t done using the Log4j vulnerability just because the media is now aware of it. Threat actors have invested a great deal of time and effort into developing this vulnerability, and they will continue to make use of it for a long time to come. As such, you are the best judge of what suspicious activity looks like on your network.
- Remediate and patch the vulnerable assets that are impacted by this vulnerability.
SecurityScorecard has created a technical report that you can download for more details about these issues and other insights we’ve gleaned thus far. Likewise, the SecurityScorecard Global Investigations team will continue investigating the Log4j vulnerability and provide updates when needed.
How can SecurityScorecard help?
In order to mitigate the potentially wide-reaching impact of this vulnerability, organizations must proactively conduct timely assessments of their own ecosystems and their vendors. SecurityScorecard is here to assist your response. with these 5 steps you can take now:
- Check if your organization is impacted: Any organization with assets running a version of Log4j above version 2.0 and below version 2.17.0 (the most recent fixed version release) is likely impacted by the vulnerability. Review your most recent vulnerability scan results, which likely contain the location of any Log4j installations active within the environment.
- Update to Log4j version 2.17.0 right away: The latest version can be found on the Log4j download page. In order to be installed, this patched version requires a minimum of Java 8. It is also important to verify that multiple Log4j installs are not present on an impacted machine, as this can mean that multiple configuration files exist.
- Bulk assess vendors with our Log4Shell Questionnaire: Send our questionnaire, “Log4Shell Questions”, now available in Atlas, to your entire vendor base. If you already have Atlas, you can leverage this questionnaire to send to your third parties right away. If you don’t have Atlas, you can sign up at atlas.securityscorecard.io or watch this video and take advantage of 5 free credits that you can use to send questionnaires.
- Proactively share your Log4Shell questionnaire with your business partners: Leverage Atlas to proactively fill out the Log4Shell questionnaire for your own organization and share it with your business partners, letting them know what your organization is doing to address the situation. This is a free feature in Atlas available to all SecurityScorecard customers.
- Understand which vendors are potentially impacted: We have published a new informational signal in SecurityScorecard called “Vulnerable Log4j Version Detected”. This informational signal does not impact scores and appears on Scorecards where a vulnerable Log4j instance was detected as of December 14th. If you see this signal on a vendor’s scorecard, reach out to them right away.
You can also check your cyber posture for thousands of vulnerabilities within an instant by signing up for your free SecurityScorecard account.
