Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > Author: Kent Backman

RSA NetWitness Platform

3 Posts authored by: Kent Backman Employee

RSA FirstWatch would like to thank the Target Cyber Threat Intelligence & Detection Team for sharing technical insight into the topic of this post.


Well into the holiday season, people are making their shopping lists, recovering from Black Friday and Cyber Monday, and perhaps contemplating the many things for which they are grateful.  Criminals, too, are making their lists, and posturing for the big shopping days ahead. 


Threat researchers are still at work of course, so it was inevitable that FirstWatch contemplated which things credit card stealing criminals--AKA “carders” appreciate.  This is what we came up with.


What carders are thankful for this year

1. Malicious code and techniques shared by other criminal developers
2. Merchants that still use swipe-only Point of Sale (POS) systems
3. Merchants with POS systems that lack Point-to-Point (P2P) encryption of payment card data
4. Merchants that employ antivirus easily bypassed by unsophisticated malware


With a combination of one or more of these carder’s favorite things, intruders have stolen payment card data associated with millions of consumers (like us), resulting in tens of billions of dollars of losses annually.[i]


We would like to illustrate a carder’s favorite thing number four with a sample of malware uploaded to the VirusTotal website on Tuesday morning, 21 November 2017, detected by zero out of 65 different antivirus vendors (Figure 1).


Figure 1 Zero detection POS RAM-scraping malware uploaded to VT


Certainly this won’t be the last POS malware not detected (statically and initially, at least) by any antivirus, nor is it the first. Consider the analysis of the zero detection Getmypass POS malware by Nick Hoffman during the holiday season three years ago[ii]


“While this isn’t the most advanced POS RAM scraper there is, it’s still capable of bypassing all 55 AV’s used to scan it.”

Three years later, there are now ten more antivirus vendors represented on VirusTotal, whose static scans are still bypassed by this recent iteration of payment card information stealing malware.


By their very nature, merchant POS intrusions are rather targeted, and if the minimal barrier to installation of their payment card collector/exfiltrator is an antivirus, merchant intruders so far continue to effectively bypass that minimal barrier.


FirstWatch would like to use this post to expose this particular campaign that unfortunately has been active since at least February of this year, with indications that thousands of credit card numbers from targeted merchants are being exfiltrated to the perpetrators at this very moment.  With any luck, we hope to make this perpetrator’s holiday season perhaps a little less enjoyable than yours. Will use some of the tools at our ready disposal, namely NetWitness and What’s This File, to peer into its behavior.


This malware is a variant of FrameworkPOS, and shares some code with other POS malware families variously known as TRINITY, BlackPOS, and BrickPOS, so we have decided to call it GratefulPOS, because, well, tis the season.


A set it and forget it stealer, not a controller

This is a tool designed to scrape and exfiltrate payment card information from one or more processes in use by a Windows-based Point of Sale system, from probably a wide variety of POS vendors.  Compiled for x64 architectures, we can assume that this malware is designed to run on POS systems running Windows 7 or later. It has no command and controller capability itself; the perpetrator uses other means of privileged access to install and execute the malware on the target POS systems.


GratefulPOS has the following functions

1. Access arbitrary processes on the target POS system

2. Scrape track 1 and 2 payment card data from the process(es)

3. Exfiltrate the payment card data via lengthy encoded and obfuscated DNS queries to a hardcoded domain registered and controlled by the perpetrators, similar to that described by Paul Rascagneres in his analysis of FrameworkPOS in 2014[iii], and more recently by Luis Mendieta of Anomoli in analysis of a precursor to this sample[iv].


GratefulPOS WTF Score

A high threat score of 80 is computed when GratefulPOS is submitted to RSA What’s This File (, Figure2)


Figure 2 GratefulPOS scores a high 80 on WTF


NetWitness Endpoint and GratefulPOS

The GratefulPOS sample was executed on a renamed but otherwise stock Windows x64 VM running NetWitness Endpoint, and analyzed through the NWE UI. 


The malware installs itself as persistent Windows service, with a legitimate sounding name “TrueType Fonts Management Service” (Figure 3).


Figure 3 GratefulPOS Windows service


Combined risk and Instant Indicators of Compromise (IIOC) score rose significantly from 23 (Figure 4) to 159 (Figure 5) after the malware installation.


Figure 4 NetWitness Endpoint before GratefulPOS execution


Figure 5 NetWitness Endpoint score after GratefulPOS execution and installation


NWE reveals the process memory scraping activity typical of RAM-scraping POS malware, by tracking GratefulPOS’s access to consecutive processes on the system in the Tracking panel (Figure 6).



Figure 6 GratefulPOS process memory scraping observed in NWE tracking panel


More credit card numbers, more DNS traffic

GratefulPOS has a simple and efficient method of exfiltrating scraped payment card data to the perpetrator by means of DNS queries to a malicious controlled domain and DNS name server daemon.  This method can typically bypass firewall and other enclaving set up on a merchant’s POS network infrastructure because the compromised POS system does not need to communicate directly to the Internet.  It can just as easily communicate to an internal DNS server on the merchant’s network, which would presumably pass on the payment card data encoded in the DNS queries, to the perpetrator.


We observed the initial DNS “check-in” beacon communication on our test system in NetWitness Packets, that sent information about the compromised system to the perpetrator.



44105+ A? (166)



44105 1/0/0 A (182)


Beacon communication was to a public DNS server (lower part of Figure 7), however, it could have been to an internal DNS server, further hiding its origins on a large enterprise network by the time it leaves the perimeter.


Figure 7 GratefulPOS malware initial DNS beacon communication to public DNS server


To add insult to injury, the domain was not selected at random.  It was designed to mimic legitimate DNS queries typically encountered in volume on large enterprise networks, associated with the large Content Delivery Network (CDN) service Akamai.  We have reached out to Akamai with this information.


We used NetWitness Packets to observe GratefulPOS perform a web check-in to the malicious name server on port 80.  The web server responded with a page that displayed the compromised system’s public IP address (Figure 8).


Figure 8 NetWitness 11 display of GratefulPOS malware web check-in with public IP response in body


It appears that the malware developer created their own IP information service, perhaps to help them organically track the source and public network infrastructure of their targeted POS systems, rather than using one of the many free services available such as, or


We also generated a few hundred fake credit card numbers and formatted them as would be encountered on a real POS system, and observed via NetWitness as the payment card information flew out the door via encoded DNS to the still clearly active exfiltration node (Figure 9).


Figure 9 GratefulPOS exfiltrates credit card numbers as observed with NetWitness


Compared to the sample analyzed by Mr. Mendieta of Anomali in 2015, we observed only minor code changes.  Instead of the particular campaign specified by “grp” strings, we see “v1702” is the campaign identifier, as displayed in an exfiltration packet (Figure 10).


Figure 10 Encoded Track 1 data with campaign identifier "v1702" as observed in NetWitness 11 event analysis


Implications and Conclusions

As Paul Rascagneres suggested, this DNS exfiltration method employed by the POS malware is clever.  It effectively negates a common POS system control employed by payment card merchants, which is blocking direct access to the Internet from the POS systems.  If the POS systems point to internal DNS servers, this malware should have no problem exfiltrating credit card data en masse without direct connect to the Internet.


Keen visibility of enterprise endpoints and network traffic allows an analyst to detect business and customer-critical threats not otherwise detected by antivirus. Hardware-enabled Point-to-Point encryption of payment card data would prevent RAM scrapers like FrameworkPOS and GratefulPOS from working at all. In absence of that, one strategy as mentioned by Mr. Rascagneres from GData includes DNS domain whitelisting of only necessary domains needed for POS function.


Indicators of Compromise

The exfiltration domain and current exfiltration DNS server IP address have been added to the RSA FirstWatch C2 Domains and IPs feeds.


Table 1 GratefulPOS Indicators of Compromise

GratefulPOS MD5


GratefulPOS exfiltration domain 

Current Exfiltration DNS server








By Kevin Stear, Justin Lamarre, Ahmed Sonbol and Kent Backman




On November 14th 2017, the US-CERT released two Technical Alerts (TA17-318A and TA17-318B) on North Korean government cyber activity, aka HIDDEN COBRA, behind broad targeting of multiple sectors in Asia and the West.  Both Symantec and Novetta have also previously documented prior campaigns by this nation-state actor, with follow-on analysis by Bluecoat and others.


FirstWatch assesses that HIDDEN COBRA high-level objectives include acquisition of hard currency, access into high value networks for later stage strategic effects, and collection of sensitive information (i.e., espionage).  HIDDEN COBRA leverages compromised third party systems as operational relay and exploitation nodes, and delivers malware via drive-by download, spear phishing, watering hole and supply-chain attack methods.



Current campaigns by this Advanced Persistent Threat (APT) group have focused on delivery of the VOLGMER Backdoor, FALLCHILL Remote Access Trojan (a relative of DESTOVER), and most recently Android malware.  As these malware are discussed in detail in previous US-CERT and Industry reporting, this blog will instead focus on detection of HIDDEN COBRA malcode in the NetWitness Suite.


It is important to note here that this HIDDEN COBRA malware does demonstrate a somewhat impressive level of technical sophistication.  In addition to the use of DLLs for process injection, the malware has significant VM evasion and sleep/delay capabilities (Figure 1).


Figure 1. VOLGMER's long and random sleep routine


Despite some of this complexity the VOLGMER executable has a number of blank file property fields, which are often good indicators of maliciousness (Figure 2).


Figure 2. Unusual empty file property fields in VOLGMER backdoor dropper


NetWitness Detection of HIDDEN COBRA

Perhaps the most easily recognizable sign of HIDDEN COBRA activity in network is the fake TLS handshake used for Command and Control (C2) in several strains of the APT group’s malware.  This activity is detected in NetWitness Packets as an alert on “unknown service over SSL port” as demonstrated by traffic from a machine infected with FALLCHILL (Figure 3).


Figure 3. Non-SSL C2 traffic of FALLCHILL malware flagged by NetWitness


NetWitness Endpoint also detects FALLCHILL by noting the malware’s unsigned process and network activity (Figure 4), which correlates to the traffic observed in NetWitness Packets in Figure 1.


Figure 4. HIDDEN COBRA FALLCHILL malware as observed in NetWitness Endpoint


For activity associated with the VOLGMER Backdoor, the NetWitness Suite also provides several means of detection.  The most consistent artifact in samples identified thus far is the “Mozillar” browser compatibility identifier name (it should be Mozilla) within user agent (UA) strings seen in the initial C2 check-in/beacon (Figure 5).  


Figure 5. Telltale "Mozillar" User Agent identifier in VOLGMER beacon


VOLGMER also employs a number of seemingly random UA strings for this C2 function.  While it is unclear the purpose of these variances, we observed six completely different UA strings and varying HTTP headers over a few seconds from a single infected machine (Figure 6). 


Figure 6. VOLGMER's jumbled HTTP connections upon initial C2 check-in 


Examination of the codebase indicates that nine different UA strings may be used for the C2 check-in (Figure 7).


Figure 7. Various User Agent strings employed for VOLGMER C2 beacon as seen in malware code


Advanced features in the NetWitness Packet’s HTTP_Lua parser provide additional indications for this VOLGMER activity with meta tagging in the service.analysis field for “not good Mozilla” and “http 1.0 unsupported connection header”.  These tags should be signs to the security analyst that something is not right and worthy of immediate investigation (Figure 8).


Figure 8. Suspicious HTTP artifacts flagged by the HTTP_Lua parser in NetWitness


NetWitness Endpoint also provides indications of VOLGMER infections by flagging the process responsible for the malware’s C2 behavior that uses contrived host headers with random domains (Figure 9).  This is well described in the Volgmer analysis report (MAR) from the US-CERT.



Figure 9. VOLGMER C2 check-in with unusual crafted HTTP artifacts and domains



HIDDEN COBRA has historically been often dismissed as a top tier threat group; however recent activity demonstrates the APT group’s ability to compromise a broad assortment of direct and indirect targets using above-average (and improving) malware development and deployment capabilities.  


While it is likely that HIDDEN COBRA will continue to harvest new infrastructure for use in ongoing campaigns, all existing Indicators of Compromise (IOCs) from US-CERT reporting as well as IOCs related to the group’s Android malware targeting Samsung users (reporting by McAfee and Palo Alto Unit 42) have been incorporated into RSA FirstWatch’s Third Party domain and IP address feeds since November 15th.


IOCs are increasingly perishable (especially from advanced actors) and limited in their effectiveness, and analysts should also leverage NetWitness and the techniques described in this post to identify any HIDDEN COBRA-initiated malware and related infrastructure that has yet to be identified.


HIDDEN COBRA meta values:

threat.source = ''

threat.category = ‘hiddencobra’

threat.description = ‘volgmer’ or threat.description = ‘fallchill’


While threat hunting, RSA FirstWatch came across a curious exposure in Windows PCs, involving driver packages provided by a certain manufacture of audio streaming controllers.  These USB audio streaming controllers are found in third-party hardware products used principally by audiophiles and PC game enthusiasts.  Distributed between 2013 and 2017, packages from this chip maker were observed to silently install a self-signed root certificate into the PC’s Trusted Root Certification Authorities store.


The purpose of this post is to briefly describe the exposure of what we have nicknamed “Inaudible Subversion,” discuss root certificate store subversion exposure in the context of NetWitness visibility, and provide remediation steps should you be an audiophile or gamer with an exposed PC.  In the big picture of things, we think that Inaudible Subversion may be a vulnerability of low--if any--consequence, but illustrates the influence of market forces behind hardware vendor sustainment of a still-popular operating system that is no longer supported by Microsoft.


Through reach-out via trusted partners, we established contact with the chip maker who acknowledged the problem, and who then began providing updated driver packages to many of its affected third-party hardware vendors, at least a dozen of which we had identified.  The new driver packages no longer have the root certificate installing routine, at the cost of no longer supporting Windows XP.  Still the updated driver packages do not remove the root certificate(s) in question, which is why we are providing remediation steps necessary at the end of this post.  Mitre assigned this exposure the identifier CVE-2017-9758, but was initially tracked by HITCON ZeroDay project as ZD-2017-00386


Problem details

FirstWatch found that specific driver installer packages provided by Savitech to their hardware vendor customers for distribution to end users, silently installed a SaviAudio root certificate into the PC’s Trusted Root Certification Authorities store (simply: trusted root store). When we say “silently” we mean that the driver installer package installs a self-signed SaviAudio root certificate to the PC’s trusted root store and Trusted Publishers stores, prior to the standard dialog box presented to the user confirming a driver (and trusted publisher certificate if so checked) to be installed (Figure 1). 


SaviAudio self-signed root certificate installed prior to Windows Security dialog box

Figure 1 SaviAudio self-signed root certificate installed prior to Windows Security dialog box


Checking the “Always trust software from [publisher name]” check box would normally be required, prior to a program installing a certificate in to a PC’s trusted publishers store. In our testing, checking the “Always trust software from Savitech Corp.” box in the driver installer routine would install a valid Savitech Corp. Verisign-issued certificate into the trusted publishers store, with the previously “silently” installed self-signed SaviAudio certificate (Figure 2).


Valid Verisign-issued certificate added to same store as the self-signed certificate

Figure 2 Valid Verisign issued certificate added to same store as the self-signed certificate


The executable responsible for the SaviAudio self-signed certificate install, SwCoInst.exe, is named the same in each MSI file package FirstWatch was able to find. It is sometimes branded with the Savitech hardware vendor’s name in the executable file properties. The SwCoInst.exe executable writes the SaviAudio certificate file NewCert.cer, as well as a valid 2009 version of Microsoft’s Certificate Manager tool, CertMgr.exe, embedded inside (Figure 3). Prior to the completion of the driver package installer routine, CertMgr.exe and NewCert.cer are deleted from the program’s folder.


Three components responsible for root store subversion function in affected Savitech driver packages

Figure 3 Three components responsible for root store subversion function in affected Savitech driver packages



An arbitrary certificate added to a Windows trusted root store, breaks the hierarchical trust model of Windows, giving significant power to the owner of the private key corresponding to that certificate, the same as any Certificate Authority (CA) behind certificates normally found on Windows systems.  Usually, only a certificate issued by Microsoft would have “All” in the root certificates Intended Purposes field.  Note: many large enterprises will typically install an “All” purposes root certificate on their Windows PCs to perform SSL decryption at the perimeter for outbound traffic, for network defense purposes, but that is typically the only exception.


An attacker who is able to obtain the corresponding private keys used to create the two known Savitech “SaviAudio” root certificates can generate any number of certificates signed by the otherwise untrusted Savitech private key.  Any system installing the Savitech drivers from any one of many vendors will trust any certificate issued by the SaviAudio CA, for “All” purposes. An attacker may spoof web sites and other online services and applications, sign software and email, as well as decrypt network traffic. Common attack scenarios include impersonating a web site, performing a Man-in-the-Middle (MITM) attack to decrypt HTTPS traffic, and installing malicious software.

In best-case scenarios, Inaudible Subversion is a minor exposure

We assess that the Savitech driver developers were conscious of the affect of driver warning alerts for XP users[i], and subsequently came up with a clever way to seamlessly support Windows XP through Windows 10, using a single driver package, without increasing support calls to their hardware vendors. In spite of being officially un-supported by Microsoft for years, Windows XP is still a rather popular operating system, especially in Asia[ii], and that might generate some substantive demand from end users of Savitech products.  On the other hand, users of Windows XP with even the latest available patches[iii] are already facing such security challenges that a self-signed certificate for which the private key is hopefully carefully guarded by Savitech, provides negligible additional exposure. There are notable incidents[iv][v] where the extractability of corresponding private keys made such kind of exposure much more serious, but this is not the case with the Savitech root certificates.


The crux of the issue is that the workaround specifically designed to accommodate the demand for hardware support for an operating system no longer supported by Microsoft, also effects any other Windows operating system on which the driver installer package is run.  This is the case with the affected all-in-one driver packages from Savitech, which do not discriminate by Windows version in their root store subversion routine.  Which means the exposure to a much more secure operating system than Windows XP, from a subverted trusted root certificate store, probably exceeds a negligible level.


In our testing with actual audio hardware purchased from a Savitech vendor, removing the SaviAudio root certificates from our test Windows XP laptop after the Savitech hardware drivers had been successfully installed, caused no issues. Our test PC with Savitech hi-fi system[vi] worked perfectly at the extremely high 352.8 khz sampling rate of our test audio file, the same as before the root certificate was removed (Figure 4).  And we confirmed that the root certificate was not needed for installing the Savitech drivers for any other Windows version besides Windows XP.


Demonstration that Savitech hardware drivers on Windows XP worked perfectly with SaviAudio root certificate removed

Figure 4 Demonstration that Savitech hardware drivers on Windows XP worked perfectly with SaviAudio root certificate removed


If given the chance, we would pass on to Savitech that they do not necessarily need to stop supporting Windows XP. However, we suggest that they provide a completely separate driver installer package for Windows XP, than for other supported Windows OSs.  Additionally, Savitech should specifically modify the Windows XP driver package installers so that the SaviAudio certificate is removed from the PC’s trusted root store after the drivers have been installed. To caveat our suggestions, we have not tested multiple hardware platforms or the root certificate removal’s compatibility with the SaviAudio mobile applications[i][ii] that can control Savitech PC audio hardware over the network.

So why should we care about an inadvertent vulnerability from a friendly audio chipmaker?

If we have written this much about a nearly inconsequential vulnerability on an RSA product-focused site, you might figure that there is a product tie-in.  And you would be right. In fact, it was Inaudible Subversion research that got multiple analysts and engineers at the RSA NetWitness team pondering.  Specifically, we pondered on the consequences of not being able to observe a self-signed root certificate being maliciously installed in a PC’s trusted root store.  One only needs to point to some notable crimeware campaigns to realize that the consequences could be significant.


Consider the Retefe Banking Trojan campaign[i] as investigated by Palo Alto Unit 42 in 2015.


Retefe uses the Windows PowerShell to execute a series of commands that installs a new root certificate on the system and a proxy configuration to re-route the traffic to the targeted banking websites.

The Retefe Trojan writes the root certificate to the disk and then uses the following command to install it on the system.

certutil -addstore -f -user ROOT ProgramData\cert512121.der


Avast also investigated a Retefe campaign[i] in 2016 with the same characteristic subversion of the target PC’s trusted root store.  FirstWatch also posted on a more recent Retefe campaign last month on RSA Link[ii], the malware of which also installed a fake but realistic-appearing certificate in the infected system’s trusted root store.   Finally, consider the RTM Banking Trojan as dissected by ESET in February of this year[iii]. RTM has a modular command switch specifically used to install a certificate into the infected PC’s trusted root store. 


With these malicious illustrations in mind, we know that it is important for an enterprise security team to be able to detect if a system’s root certificate store has been subverted. Currently, detecting a certificate being added to the trusted root store of a PC protected by NetWitness Endpoint, requires some extra configuration in NetWitness Logs, or Sysinternal Sysmon installed on a PC such that tracking events similar in resolution (Figure 5) to NetWitness Endpoint tracking logs, be sent to a NetWitness log decoder.


Sysmon logs showing root store subversion by Savitech self-signed certificate

Figure 5 Sysmon logs showing root store subversion by Savitech self-signed certificate


Client side Windows logging can be a mixed bag of Windows policies pushed by GPO or other endpoint tools that harvest these specific events.  If your Windows logging policy includes event ID Security/4688 (detailed tracking and audit process creation) you will be able to see these events but beware, event ID 4688 is very high volume.  If covering the endpoint with Sysmon is more your style, with the right template you will be able to capture the events via WMI into NetWitness logs under event ID sysmon/1 which look like Figure 5 above in event viewer and Figure 6 in NetWitness logs.


Sysmon event via NetWitness Logs

Figure 6 Sysmon event via NetWitness Logs


If you have NetWitness Endpoint and are pulling tracking data out via ODBC you will see events like Figure 7.


NetWitness Endpoint tracking data

Figure 7 NetWitness Endpoint tracking data


And if you have the latest NetWitness Endpoint 4.4 you can enable the meta integration service and get tracking data and more, which would get you information like Figures 8 and 9.


NetWitness Endpoint 4.4 meta integration

 Figure 8 NetWitness Endpoint 4.4 meta integration


NetWitness Event Analysis

Figure 9 NetWitness Event Analysis


Having the data available in one single interface is part of the solution, being able to alert on those events proactively is a much more scalable solution.  Using the Application rules below you can create proactive alerts for these events (the first three rules group Sysmon events, NW Endpoint ODBC and NWEndpoint events together).


name="endpoint-event-include" rule="device.type='nwe_tracking' && category='createprocess'" alert=analysis.session type=application


name="endpoint-event-include" rule="device.class='windows hosts' && ='1'" alert=analysis.session type=application name="endpoint-


event-include" rule="device.type='nwe_tracking' && category='createprocess'" alert=analysis.session type=application name="endpoint-event-include"


rule="device.type='nwendpoint' && action='createprocess'" alert=analysis.session type=application name=p3_certmgr-add-local-root-cert


rule="analysis.session='endpoint-event-include' && process ends '\\certmgr.exe' && (param contains '-add' || param contains '/add') && param contains


'localmachine'" alert=analysis.session type=application name=p3_certmgr-add-local-root-cert rule="analysis.session='endpoint-event-include' &&


filename.dst='certmgr.exe' && query contains '-add' && query contains 'localmachine'" alert=analysis.session type=application name=p3_certutil-add-


local-root-cert rule="analysis.session='endpoint-event-include' && filename.dst='certutil.exe' && query contains '-add' && query contains 'root'"


alert=analysis.session type=application


In this case the alert sends information to the Session Analysis metakey (analysis.session) which you could turn into an alert or include in a summary report to review on a daily basis.


Session analysis alert key for root certificate addition

Figure 10 Event Alert


The detection can be mapped to Mitre Att&ck  T1130[i] under Defense Evasion for install Root Certificate.


Not wanting to leave good enough alone, expect a part two to this blog post in the not so distant future.  We don’t think root certificate subversion is going away any time soon, and the subject needs more attention from us before we can rest at ease.



In the big picture of things, Inaudible Subversion might be considered an inconsequential vulnerability, as it effects principally audiophiles and video game enthusiasts of third party hardware vendors.  We also presume that the not insignificant die-hard base of Windows XP users has more pressing security concerns with their PC, than a self-signed root certificate from their friendly audio manufacturer.  While the root certificate routine in these driver packages is not limited to running on Windows XP, additional testing showed that removing the self-signed certificate from the Trusted Root Certification Authorities store did not cause any issues, even on Windows XP.  The certificate was only “needed” during the time that the Windows XP drivers were installed, and on our test platform, the audio hardware worked fine when the self-signed certificate was subsequently removed from the PC.


To Microsoft’s chagrin, we think that the manufacturer would be able to safely support their base of Windows XP users, by including the drivers for Windows XP in an installer package separate from the installer package for Windows 7/8.x/10.  Also, in the separate Windows XP package, they could provide a simple routine to remove the self-signed certificate, following the driver installation.   


Finally, we got to the point of our product-tied post, which is making sure that you can see when someone other than a friendly audio maker subverts a PCs root certificate store.  While we can currently guide you on making your NetWitness products “root subversion ready,” we pledge that it needs to be more out of the box.  So we are working on it.


This post was made possible by special contributions from Eric Partington.


FirstWatch would like to thank Ziv Chang of Trend Micro, Allen Own of HITCON ZeroDay, Asus Product Security Team, EMC Product Security Response Center, and CERT/CC for their assistance.




















Filter Blog

By date: By tag: