Your quick reference guide to align enterprise cybersecurity with DoD’s shift to Zero Trust
Since its inception in 2010, Zero Trust Architecture has taken the cyber defense world by storm as a way to account for the evolving threat landscape and changing cloud and hybrid IT environments that function without a precise network perimeter. Consequently, over the last two years or so, there’s been an influx of strategic guidance, policy, execution roadmaps, and other cybersecurity risk management resources surrounding the Department of Defense’s (DoD) transformational shift to a “Zero Trust.”
As with many cybersecurity hot topics, the initiative is often laced with vast marketing promises and relentless attempts to communicate the ever-increasing need to buy a tool (“silver bullet”) to solve the problem or, in this case, get to Zero Trust security.
With the Department navigating the Zero Trust waters and unpacking the myriad of capabilities and activities necessary to formulate a robust implementation plan (due to the DoD CIO by October 2023), BreakPoint Labs offers clear, actionable steps for any organization to self-evaluate its current program and begin its journey towards achieving a Zero Trust Architecture.1
Avoid falling prey to the solicitation of purchasing a new, shiny Zero Trust capability, especially early on in the process. The DoD defines the Zero Trust baseline as one that “leverages its current infrastructure and environment using Brownfield approach.”
In other words, it retains key elements of the existing perimeter-based methodology and applies them within the modernized Zero Trust model. Considering the depth and breadth that consists of more than 45 capabilities and 152 activities that comprise the DoD Zero Trust Strategy, there’s ample opportunity to put existing investments to work within the new paradigm.2
A foundational step to Zero Trust is understanding who and what is on the network. At the most basic level, you can’t protect and defend components unmanaged or unaccounted for.
Establishing and validating a current, accurate inventory of all users, including person and non-person entities, is critical to ensuring those with access to resources are vetted and registered from an authoritative source.
In addition to users, organizations must inventory devices to validate what systems are authenticated, authorized, and connected to other network resources. While creating or verifying an inventory seems administrative, doing so in a trusted, standardized, and data-driven manner will pay dividends in the later stages of the Zero Trust journey.
With an understanding of who and what is on the network, an organization can designate Identity, Credential, and Access Management (ICAM) solutions to serve as an authoritative source for identities and subsequent authentication and authorization decisions.
Before the release of the Zero Trust Strategy in 2020, the DoD released an ICAM Strategy (if you’re seeking yet another strategy) focused on “the creation of digital identities and maintenance of associated attributes, credential issuance for person/non-person entities, authentication using the credentials, and making access management control decisions based on authenticated identities and associated attributes.”
The need for a well-defined and well-informed ICAM solution is apparent. It’s essentially the “quarterback” of the Zero Trust architecture responsible for many downstream decisions on user authentication and authorization.
A secure trusted environment where people and non-person entities can securely access all authorized resources based on mission need, and where we know who and what is on our networks at any time.
DoD ICAM Strategy – Vision
Like user identities, devices must also be pinpointed and inspected before accessing network resources. Ensuring systems are not only what they say they are but also verifying they satisfy a minimum baseline of vulnerability or patch management levels — letting you drastically reduce risk within the environment.
Comply-to-Connect (C2C) capabilities have advanced significantly in recent years, especially considering the increased use of remote access during and following the COVID-19 pandemic.
C2C allows for real-time inspection of devices and comprehensive policy decisions that best suit the needs of the organization and its users. A well-instrumented C2C solution will be a critical source for device authentication decisions.
With the foundational building blocks of a Zero Trust Architecture in place, organizations can begin to focus on interoperability, automation, and analytics. Using application programming interfaces (APIs), organizations can automate repetitive, predictable processes, including:
As Zero Trust implementations mature, organizations will transform into data-rich environments that conduct cybersecurity monitoring through various information logs such as user, device, applications, and network activity — offering limitless options for behavioral analytics to characterize, monitor, and continuously evaluate the enterprise cybersecurity posture.
The adoption of Zero Trust principles does not happen overnight. It takes careful, deliberate planning and continuous incremental improvements to execute the framework fully.
As DoD seeks to implement distinct Zero Trust capabilities and activities by Fiscal Year 2027, the Department’s own Zero Trust Portfolio Management Office has recognized the need to “make it simpler, while still maintaining the ability…to stop the adversary.”
The key considerations and actionable steps described will jumpstart any organization’s journey toward achieving a Zero Trust Architecture.
Disclaimer of Endorsement
The information and opinions contained in this document are provided “as is” and without any warranties or guarantees. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise does not constitute or imply its endorsement, recommendation, or favoring by BreakPoint Labs, LLC.
1. DoD Zero Trust Strategy Placemats, retrieved from https://dodcio.defense.gov/Portals/0/Documents/Library/ZT-StrategyPlacemats.pdf. ↩
2. DoD Zero Trust Capability Execution Roadmap, retrieved from https://dodcio.defense.gov/Portals/0/Documents/Library/ZTCapabilitiesActivities.pdf. ↩
Operational technology is rapidly becoming a target of ransomware operations due to the business impact of taking these essential systems down and how this pressure can lead to companies paying the criminals in order to restore operations. The manufacturing industry is making significant investments in AM hardware and materials (approximately $17B in 2021). The growth of capital in this technology will attract cyber criminals. This article examines the potential targeting approach that may be used by ransomware criminals to value a company’s assets, even those not on a network.
Suppose that a ransomware group decides that organizations who can afford 3D printing are good targets of ransomware due to the need to prepare print jobs through a Windows based engineer workstation. The group realizes that most CAD (computer aided design) capable computers are fairly expensive in addition to the expense of the additive manufacturing hardware. They can use open source intelligence (OSINT) gathering from a passive perspective. Once attackers gain access to your network, they can use the tools, etc. described in the following to enumerate these engineering workstations and the corresponding OT equipment, even those that are offline but rely on digital-thread dependent processes.
After some time, a phishing attempt goes through and access is gained to engineering workstations. Now they simply have to launch ransomware tools to encrypt the workstation, locking the end user from being able to use or recover their files. This is where a note is left with instructions on how to pay the group to unlock the computer, typically through a cryptocurrency transfer. The amount requested from a victim is a critical factor for achieving the ransomware group’s goals. If the amount is too high the victim will simply ignore the ransom and cut their losses. This is where a little homework post-phishing access and pre-encryption can pay off.
Some techniques to automate this asset research can be done using the command line to extract the pertinent information. First, the workstation itself is a valuable resource that needs to be taken into consideration when setting a ransomware value. In the example table above the Command MSInfo32 /report report.txt is used to get the make and model of the compromised AM Workstation.
Next up is researching OT resources. This is a little more difficult and requires more prep and background knowledge of the AM process. Many 3D printers lack network capabilities so one would think a remote attacker with zero physical access would struggle to determine what assets a manufacturer has. This is not the case. Running this hardware requires leaving “digital footprints” on the engineering workstation of these expensive, non-networked hardware items. One method to detect the OT hardware is to open and inspect the slicers, such as in the image below.
This method works but is time consuming and can be a step whereby the end user discovers the intrusion. A better solution is to again use the Command Line to gather this information for us in the background. A database containing the standard directories used by the most common slicing utilities and versions would be the best method to automate this task. The blind spot here is that non-networked assets do not have an instance number. For example, an AM operation could have 10 Taz Pro printers but only reflect one in the slicing utility / RoamingData.
The ability to detect and prevent this type of fact gathering intrusion extends a company’s security posture beyond protecting against ransomware. This post focuses on setting a monetary value for ransomware purposes but there are many other pivots an attacker could achieve with this information depending on their end goals. If they wanted to achieve destructive attacks on manufacturing they could use this information to create relevant attack strategies based on the available attack surface. If a machine is found to have G-code articulated stepper motor drivers those printers would be candidates for current overheating based attacks compared to machines that rely on trimpot physical adjustments. Knowledge stolen from the slicer configs also tells an attacker what firmware a device uses so they can research the developers and if open-source obtain a copy to maliciously modify for gaining persistence on a non-networked device. It will be easy to identify the transfer media (USB, SD card) based on the printer information to jump the “air-gap” to a resource that is supposed to be unreachable.
The impact of intellectual property theft in the prototyping / R&D phases where these AM assets are most leveraged is incredibly large. One of the best ways to protect or respond against this threat is to recognize that AM operations are at risk and the information to subvert these processes is widely available due to the reliance on open-source-software. This is amplified by the “insecure by design” equipment manufacturers tend to adopt as cybersecurity is not a topic in the development of physical manufacturing equipment. This leads to no native visibility into the environment from a security perspective. These facts fueled the development of BISON to gain the visibility needed to secure R&D / intellectual property during manufacturing stages.
If you are interested in learning more about securing AM or a demonstration of the BISON capability, please contact us at info@breakpoint-labs.com
Ref: Ginter, Andrew, and Greg Hale. “OT Security Incidents 2021 Trends and Analyses.” ICS STRIVE, 2022, pp. 4–4., Accessed 12 June 2022.
With recent world events, ransomware is a foremost concern in cybersecurity. RagnarLocker has made headlines after compromising 52 critical infrastructure entities. Additive manufacturing equipment, while not a traditional target of ransomware, is not immune from these threats. Here we demonstrate simple ransomware that is easily implemented by abusing a built-in function of Marlin and substituting a graphical menu. Last week we demonstrated an attack on additive manufacturing file integrity. This post pertains to the availability category.
A mocked up ransom note was created using a Google Slide and the link turned into a QR code. Marlin has a utility to assist developers in creating custom menus for the types of graphical displays most commonly used (non touch screen, encoder wheel navigation). This is how the ransomware note QR image is converted into the C code needed to replace the Lulzbot logo in the boot sequence.
What makes Marlin so ubiquitous is the fact that multiple Hardware Access Layers (HAL’s) are supported once a configuration has been created in an IDE. This means that Marlin is able to be run on many different physical hardware components – AVR, STM32 and Arduino to name a few. In this thought experiment we are using Visual Studio to configure the C code blocks to match our physical hardware and enable locking a user out of their own device via misuse of a “dormant” library containing locking functionality meant to be used for access control. Once configured – which is just a few steps more difficult than uncommenting that block, we will use the Marlin AutoBuild VSCode Extension to compile our compromised firmware. This process is simple, removing the need for specific AM knowledge.
A slight modification of this would make the QR code stay on the screen and not change to the password input. Users would assume this is a built-in diagnostics message and not think twice about scanning the QR code. This is a problem as the machine maintainer has now accessed an untrusted third-party site where further exploitation could occur.
Ransomware attacks diminish trust in the environment. Regardless of whether or not a ransom is paid, at some point an intrusion occurred and significant labor costs are associated with tracking down the ingress that allowed exploitation to occur via computer forensics. Once located patches need to be applied or created. All of this causes significant disruption in the manufacturing processes reliant on the now compromised devices. Interested in protecting your manufacturing operations against OT targeted ransomware? Want to avoid missing delivery of critical client deadlines due to cyber intrusion? Contact BreakPoint Labs for more information about how BISON can secure your manufacturing networks!
If you are interested in learning more about securing AM or a demonstration of the BISON capability, please contact us at info@breakpoint-labs.com.
The more things change, the more they stay the same. Ransomware attacks continue to disrupt organizations across all sectors while the results of law enforcement actions are waiting to be seen. We continue to monitor an effective threat group that shows no signs of slowing down.
The following domains were identified and attributed to this threat group:
| azuregroupusa.com | getprintservices.com | twebhost.com |
| chipfirmware.com | itacrobat.com | vip-source.com |
| databasegroupinc.com | mikrotikinside.com | webnofy.com |
| dmaorlando.com | release-app.net | webonlinecompany.com |
| easyupdatepro.com | slim-well.com | windows-upd.com |
| esc-ok.com | softlinesys.com | wmsmicro.com |
| eztechnet.com | sonyblueprint.com | |
| gdbcrew.com | spdevhost.com |
One positive note, we observed a distinct change in adversarial TTPs with this group in the past month. Threat actors have moved away from their preferred domain name registrar, NameCheap, to other providers like NetEarth One and Hosting Concepts B.V. d/b/a Registrar.eu.
The best defense against ransomware continues to be centered on reliable backups, active monitoring of networks and systems for vulnerabilities and weaknesses, and active patch management solutions. An ounce of prevention is worth a pound of cure. If your enterprise is missing one or more best practices, please contact us to help get you on the right track before it is too late.
If you are in need of incident response support or ways to defend against this and other threats, please contact us at https://breakpoint-labs.com/.
Since our last post at the end of August 2021, we have continued to track an effective ransomware group and they have been busy! We are tracking over 120 domains correlated to this threat group. They have been busy in October registering over 20 new domains in the last two weeks.
The following new domains have been linked to this threat group:
| academyads.com | emerictech.com | newseo.org | troncaselink.com |
| accountsupdate.org | escondidoseo.com | novadigitalgroup.com | turbojax.com |
| acronicssolutions.org | gessertmedia.com | ogsbd.com | uniselect.org |
| appinternet.net | get4tech.com | perscitech.org | unrigusa.com |
| av-sat.net | go-instant.com | phpjoblist.com | updatedlinux.com |
| bdeduinfo.com | herosoft.org | radardefence.com | updater-panel.com |
| bestupdate.net | hsncsoft.com | rdadev.com | us-time.org |
| cbdallas.org | ifftools.com | rootmailer.com | us-time.us |
| cloud-dock.net | introwebsites.com | router-manager.net | vpn-updates.net |
| cnetdownloader.net | ircontent.com | rq-technologies.com | wget-upd.com |
| codegemba.com | iweb-tech.com | shopyscripts.com | wiredobserver.com |
| codessional.com | jetkm.com | slot-download.com | wmi-technologies.com |
| competitionsites.com | metasportsystems.com | smlsystem.com | wotsafe.org |
| crmdevnet.com | mkvdb.com | sourangroup.com | zacstech.com |
| database-updater.com | msbackupservice.org | tebo-tech.com | zeoplan.com |
| datasecuritytoday.com | mysafexpress.com | tmdiagnostics.com | zoncat.com |
| devpda.com | new-release.net | top-enter.com | zorandev.com |
As you can see above, they continue to follow technology-related domain schemes. Each domain is hosted on a VPS with similar ports, protocols and services. During our analysis, we identified the actors running “Metasploit 4.20.0 – Update 2021083001” – a recent and likely cracked version of Metasploit.
This threat group is very active and has better tradecraft than other threat groups. The actors utilize non-standard ports, recently expired domains, employ trusted Let’s Encrypt certificates and do not reuse infrastructure to blend in with legitimate traffic that is not easily searchable. By proactively identifying their infrastructure we are able to prevent this threat and others like them from compromising our customers.
If you are in need of incident response support or ways to defend against this and other threats, please contact us at https://breakpoint-labs.com/.
During the course of multiple incident response engagements, we encountered a persistent, unknown ransomware threat group utilizing an obfuscated Golang encryptor
[1]. It is believed that the threat actors gained initial access through one or more SonicWall exploits [2], [3].
We can confirm prior sightings that Cobalt Strike was used by these threat actors to further gain access to exploit victim networks. In this blog, we will highlight previously unreported infrastructure that is managed by this unknown threat group.
Victims are presented with the following ransom note:
Hello dear user! Unfortunately, your files have been encrypted and attackers are taking over 300 GB of your personal data, financial reports and many other documents. Do not try to recover files yourself, you can damage them without special software. We can help you recover your files and prevent your data from leaking or being sold on the darknet. Just contact support using the following methods and we will decrypt one non-important file for free to convince you of our honesty. Contact us method below: Use TOR Browser: http://[redacted].onion/[redacted]
A recent sample of the Golang packed malware was submitted to VirusTotal in mid July 2021 [4]:
| MD5 | 864e4a109565f8d4052b959a12bfa45b |
| SHA-1 | 94388841e65c0962e56bf3e37391006d0af20bf4 |
| SHA-256 | d6f7eed7e8aeffb0683639a2c5b654d216f98a68de1528ef37685103f6e24550 |
The following domains have been attributed to the unknown threat group and have been observed hosting a Cobalt Strike server using TLS/SSL on non-standard ports. It is clear that these threat groups are attempting to blend in with the noise by generating seemingly legitimate domains.
| 3comnet.biz | cisco-network.org | group-policy.org | releases-upgrade.com |
| 3comnet.net | cisco-updates.com | ibgp-cisco.com | repository-buster.com |
| advmicrodevice.com | ciscodev.org | intelfirmware.net | routeros-update.com |
| amibios-updater.com | code-signing.org | juniper-firmware.com | serviceupdate.net |
| amibios.net | dev-repository.com | juniper-vpn.net | software-repository.com |
| apps-update.net | dev-service.org | junipervlan.com | software-updater.net |
| archive-update.com | dev.updatecore.net | mikrotikfirmware.com | ubiquiti-vpn.com |
| archives-firmwares.com | developmentsdata.com | mikrotikvpn.net | unattended-upgrades.net |
| bgp-firmware.com | dlinknetwork.com | nvme-updates.com | updatepayments.net |
| buster-updates.com | dlp-systems.org | poweredge-update.com | veeamdata.com |
| cisco-cloud.net | esxi-update.net | release-update.net | vpn-updater.com |
The following IP addresses are related to the domains listed above and appear to be a single use.
| 104.129.26.226 | 170.130.28.35 | 173.232.146.43 | 23.226.132.245 |
| 104.129.26.28 | 170.130.28.37 | 173.232.98.16 | 23.94.83.123 |
| 104.129.42.67 | 170.130.55.16 | 191.101.172.24 | 45.227.255.15 |
| 104.149.216.58 | 170.130.55.160 | 192.154.213.119 | 46.161.27.19 |
| 104.223.106.239 | 170.130.55.32 | 192.154.213.122 | 64.188.19.20 |
| 107.150.19.211 | 170.130.55.97 | 192.154.224.52 | 64.188.27.154 |
| 107.150.19.72 | 172.245.247.67 | 192.3.31.17 | 66.154.102.222 |
| 162.218.210.152 | 172.245.87.3 | 192.3.99.71 | 66.154.103.212 |
| 162.218.211.139 | 173.232.146.185 | 194.165.16.98 | 66.154.112.36 |
| 162.245.191.153 | 173.232.146.218 | 198.23.141.117 | 66.63.162.170 |
| 167.160.166.12 | 173.232.146.39 | 216.244.83.66 |
This threat group has been very active and if you or your organization utilized a SonicWall SMA VPN device since late 2020 or early 2021 without limited access, there is a likelihood that your organization has been compromised. If you observe any connections to the domains listed above, it is very likely you are compromised.
1. Back up (or start backing up!) all of your critical business data to an offline location. We observed these threat actors identifying backup solutions employed by a victim and removing all backup files from an online 3rd party solution provider.
2. Patch and upgrade your SMA devices immediately. More information can be found here: https://www.sonicwall.com/support/product-notification/urgent-security-notice-critical-risk-to-unpatched-end-of-life-sra-sma-8-x-remote-access-devices/210713105333210/
3. Review all SMA logs looking for suspicious activity – specifically looking for successful authentication attempts from non-US based IP addresses and/or IP addresses that don’t originate from Internet service providers such as home or commercial ISPs.
4. Enforce multi-factor authentication for all VPN accounts.
5. Employ signatures to detect the above mentioned domains and hashes.
If you are in need of incident response support or ways to defend against this and other threats, please contact us at https://breakpoint-labs.com/.
[1] https://www.crowdstrike.com/blog/new-ransomware-variant-uses-golang-packer/
[3] https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2021-0001
A common practice in SOCs is to periodically resolve known hostile domains to identify changes in adversarial infrastructure. There are a variety of approaches to help you track hostile infrastructure but your mileage may vary. If your monitoring capabilities are tuned to look for specific domains, you may end up adding a significant number of unnecessary alerts to your SIEM. If your organization actively poisons specific DNS requests, you may just change your code to point to 8.8.8.8. Unfortunately, that approach still lets an eavesdropper see what domains you are actively resolving.
Recently, Google began offering a DNSSEC-validating resolution over an encrypted HTTPS connection to mitigate some privacy and security concerns. Essentially, you can submit domains over a secure channel and let Google do the resolution for you! The API is clean and very responsive. To help us and hopefully others track infrastructure in a secure manner, we created a simple Python client to interface with the DNS-over-HTTPS API. The code is publicly available at https://github.com/wglodek/dns-over-https.
[code lang=”py”]
>>> from dns_over_https import SecureDNS
>>> r = SecureDNS()
>>> r.gethostbyname(‘www.breakpoint-labs.com’)
u’37.60.235.49′
>>> r = SecureDNS(query_type=’AAAA’)
>>> r.gethostbyname(‘www.google.com’)
u’2607:f8b0:400d:c02::6a’
>>> r.resolve(‘www.mit.edu’)
[u’2001:590:100b:182::255e’, u’2001:590:100b:18b::255e’]
>>>
[/code]
The code turns security and privacy on by default by: 1) padding each request with a random string to minimize the probability of a side-channel attack being successful, and 2) automatically to not send any part of your IP address to the authoritative name servers.
There is a drop in replacement for Python’s `socket.gethostbyname` to turn your plaintext DNS queries into secure requests where you can have a higher degree of confidence that no one is messing with the response!
Microsoft’s Windows Defender Advanced Threat Hunting Team and Palo Alto’s Unit 42 recently published some great technical writes up that detail targeted attacks, PLATINUM and OilRig, respectively. The reports are great because they provide some actionable intelligence for network defenders to detect malicious activity. The reports also go into great detail about how the attackers encrypt/encode data in their command and control information. In this post we will use a few lines of Python code to decrypt the beacons associated with PLATINUM and OilRig implants.
Dispind is a lightweight implant that provides backdoor access to attackers to control a victim machine. Dispind uses to communicate with it’s command and control servers. The initial HTTP beacon will POST the string “ud7LDjtsTHe2tWeC8DYo8A**”, which is an AES256 encrypted and base64 encoded string. Microsoft was kind enough to put the key (“AOPSH03SK09POKSID7FF674PSLI91965”) in their PLATINUM write up. According to Microsoft, the encrypted string is effectively a bunch of whitespace. With this information, let’s write some quick Python code to see if we get the same result:
The plaintext output contains “1” followed by a bunch of white space characters. It looks like we got the expected result!
The Helminth implant uses HTTP and DNS to communicate with it’s command and control infrastructure. Unlike the Dispind.A implant, the Helminth implant utilizes the “Cookie” header field to send encrypted information. The folks over at Unit 42 discovered that this field contains information about the system and malware, which is encrypted with RC4 using a static key. Let’s see what we can do with some Python:
It worked! The OilRig technical report also goes into great detail about Helminth’s DNS C2 capability. If you’re interested in sharping your Python skills, give the DNS C2 decoding a shot.
Thanks to Microsoft and Palo Alto for sharing the in-depth technical details to make this post possible.
[1] – Helminth HTTP beacon: http://researchcenter.paloaltonetworks.com/wp-content/uploads/2016/05/OilRig_Unit42_Figure-12.png
There is no single tool that will protect your network from sophisticated actors. The biggest advantage in defending a network starts with staff that understand the terrain – hopefully better than the adversary. The biggest killer of an effective team can be tools that generate volumes of alerts or data that do not provide meaningful insight into what is happening on the network.
Sophisticated attackers may utilize many techniques to evade or avoid detection, and understanding how your network defense tools respond to unexpected inputs is important.
A report from Arbor Networks detailed an implant, Evilgrab/Grabber, that prepended five bytes of data before a legitimate HTTP request. We were interested in understanding how the five leading bytes would be analyzed by Bro IDS, an open source network intrusion detection system. We generated some pcap that mimicked beaconing traffic described in the report and ran it through Bro 2.4.1. Not surprisingly, Bro IDS generated a “bad_HTTP_request” event the weird log.
The weird log captures “unusual or exceptional activity that can indicate malformed connections, traffic that doesn’t conform to a particular protocol, malfunctioning or misconfigured hardware, or even an attacker attempting to avoid/confuse a sensor.” While technically accurate, the “bad_HTTP_request” error message is vague and can be easily overlooked but an overwhelmed staff. A more descriptive error message could mean the difference between successful detection and an ignored event.
BreakPoint Labs recently submitted a patch to Bro IDS, which was accepted, to generate a more descriptive weird event. In the Evilgrab/Grabber scenario, the legitimate HTTP request follows the five leading bytes. Our patch attempts to detect the beginning of the version string – “HTTP/” – at the end of the request method. If found, instead of generating the vanilla “bad_HTTP_request” message, we generate a more descriptive error message: “bad_HTTP_request_with_version_field”.
The additional information within the same error condition can provide the needed context to discern between unusual and exceptional. Although the patch is small, it may be the missing piece to detecting an adversary looking to evade detection.
BreakPoint Labs is in the fight to eradicate cyber pathogens through more descriptive error messages.
Detecting sophisticated cyber threats is an inherently difficult task. Understanding what systems and information may have been compromised can be even more difficult. Recently, Shusei Tomonaga & Yuu Nakamura from the Japan Computer Emergency Response Team/Coordination Center (JPCERT/CC) gave a presentation that discussed in technical detail two cyber operations targeting Japan. The presentation covers the attacker’s tactics, techniques and procedures to successfully compromise 130 organizations. Along with the presentation, JPCERT/CC released a collection of tools to detect and analyze artifacts associated with the implants mentioned during their presentation.
The attackers utilized an HTTP bot, Emdivi (t17), for initial command and control. The Emdivi implant sends data to an attacker controlled server over an HTTP connection; however, the attackers employ a custom encoding routine to obfuscate the data. The custom encoding routine functions by first generating an XOR key based on a key value, then using the XOR key to obfuscate the payload. The JPCERT/CC reverse engineered this custom encoding scheme and developed a Python script to decode the data. The script requires the analyst to have already done the sometimes tedious work of extracting the encoded information from the HTTP protocol. Unfortunately, not all cyber security operations groups have the necessary skills or resources to carve data from large volumes of network traffic, and the time from initial detection to understanding can be measured in days, weeks and/or months.
In an effort to reduce the time needed to understand an Emdivi (t17) infection, we have adapted the scripts developed by JPCERT/CC into a Dshell decoder. Dshell is a network forensic analysis framework than does the heavy lifting of reassembling network streams and parsing common network protocols, like HTTP and DNS. The decoder, emdivi_c2.py, inspects every HTTP request and attempts to identify elements within the HTTP request that are utilized by Emdivi for command and control and verify if it is authentic Emdivi traffic. A successful Emdivi event will generate an alert that contains information about the campaign and victim machine:
The decoder can be invoked by using the following command line syntax:
[code lang=”py”]Dshell> decode –d emdivi_c2 sample.pcap[/code]
The emdivi_c2.py decoder is expensive as it inspects every HTTP request and should use in conjunction with other detection capabilities.
BreakPoint Labs is committed to developing technology, capabilities, and most importantly, cyber workforce prepared to defend networks from sophisticated threats.
