{
	"id": "db867418-91db-4ee4-9052-60415a86711e",
	"created_at": "2026-04-06T00:16:27.234885Z",
	"updated_at": "2026-04-10T03:20:16.02588Z",
	"deleted_at": null,
	"sha1_hash": "d03a8439eae2ebedd71e3fc95334ce464b7a35e0",
	"title": "Research Recap: How To Automate Malware Campaign Detection With Telemetry Peak Analyzer",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1684304,
	"plain_text": "Research Recap: How To Automate Malware Campaign Detection\r\nWith Telemetry Peak Analyzer\r\nBy Jason Zhang, Stefano Ortolani, Giovanni Vigna\r\nPublished: 2021-11-11 · Archived: 2026-04-05 22:37:16 UTC\r\nCyber security threats have been growing significantly in both volume and sophistication over the past decade\r\nwith no sign of a slowdown. Naturally, this has also been accompanied by an increased collection of threat\r\ntelemetry data, ranging from detonation timelines to IDS/IPS detections. Telemetry data, typically represented by\r\nenriched time series, often contains underlying peak signals which in turn correspond to a few informative events:\r\noccurrences of malware campaigns, heavily used malware delivery vectors, commonly affected verticals, and even\r\nanomalies possibly revealing the presence of false positives. While all this information clearly holds tremendous\r\nvalue, mining these data sets can be expensive and complex. As a result, organizations often find it challenging to\r\ngain further insights of the underlying threat landscape even though they have access to the data.\r\nRecently at VirusBulletin Threat Intelligence Practitioners’ Summit (TIPs) 2021, we presented our latest research\r\naiming to tackle the challenges discussed above: Telemetry Peak Analyzer is a statistical approach to detect\r\nmalware campaigns as they happen by relying on telemetry data in an efficient and scalable manner.\r\nRead on to get the key insights of the presentation. We’ll provide an overview of the characteristics of typical\r\nthreat telemetry data collected by VMware Threat Analysis Unit (TAU) before discussing the proposed Telemetry\r\nPeak Analyzer. We’ll then evaluate the effectiveness of our approach by showcasing some typical examples of\r\ndetected malware campaigns using the threat telemetry data generated from production followed by a brief\r\ndiscussion on the usage for the open-source package.\r\nThreat Telemetry Data\r\nThreat telemetry data can be seen as a composite time series. For a given attribute or dimension such as file type, a\r\ncomposite time series can be decomposed into individual time series. For example, a file detection composite time\r\nseries could contain two individual time series such as PDF and Excel time series, as illustrated in Figure 1. As\r\nseen from the figure, even if there are some peaks from an individual time series, the composite time series\r\ndoesn’t show clear peaks.\r\nhttps://blogs.vmware.com/security/2021/11/telemetry-peak-analyzer-an-automatic-malware-campaign-detector.html\r\nPage 1 of 10\n\nFigure 1: An illustration of a composite time series representing file detections.\r\nFigure 2 shows VMware NSX threat telemetry data from production. The telemetry data is a composite time series\r\nthat comprises multiple detection time series–one for each file type. While it is hard to tell if there are any\r\nmalware campaigns (or underlying peaks) associated with certain file types by visually examining the telemetry\r\ndata shown in Figure 2, you can identify an interesting peak. However, that peak is hidden.\r\nFigure 2: A snapshot of VMware NSX telemetry data comprising multiple detection timelines, one\r\nfor each file type.\r\nIn addition, each individual time series has many detection events, and multiple detection events can refer to the\r\nsame file. An event is further characterized by metadata (see Figure 3, some fields in the figure have been\r\nanonymized).\r\nhttps://blogs.vmware.com/security/2021/11/telemetry-peak-analyzer-an-automatic-malware-campaign-detector.html\r\nPage 2 of 10\n\nFigure 3: An example of file submission event from VMware NSX telemetry.\r\nThe telemetry data discussed above poses great challenges to malware campaign detection due to the complexity\r\nof the multi-dimensional time series.\r\nNext, we introduce the proposed Telemetry Peak Analyzer.\r\nProposed Approach\r\nThe proposed Telemetry Peak Analyzer is a framework to analyze and detect peaks on telemetry data with\r\ncomposite time series. The analyzer detects meaningful peaks based on statistical measurements computed over a\r\nshort local window and a longer global window of telemetry data:\r\nLocal window: A short time data window in which we want to detect peaks of a given attribute or\r\ndimension, e.g., file type. During the detection process, the analyzer generates a local statistics table (LST)\r\nwith all the necessary statistical measurements.\r\nGlobal window: A historical long time data window that serves as a global benchmark to determine if a\r\ndetected peak within the local window is meaningful. During the detection process, it will generate (or\r\nupdate) a global statistics table (GST) with all the necessary statistical measurements.\r\nFigure 4 illustrates the detection workflow overview of the analyzer. As pointed earlier, we define two data\r\nwindows: a local window and a global window. The task is to identify legitimate peaks in the local window by\r\nleveraging the statistics in LST and GST tables through the peak detection algorithm.\r\nAfter loading the statistics sets LST and GST, the peak detection logic proceeds by performing a set of statistical\r\nthreshold-based comparisons. For instance, it compares the total event count in a local window of a given attribute\r\n(e.g., the file hashes of a given file type) to the weighted global average event count of the attribute in the\r\nhttps://blogs.vmware.com/security/2021/11/telemetry-peak-analyzer-an-automatic-malware-campaign-detector.html\r\nPage 3 of 10\n\ncorresponding global window. A valid peak is detected after certain conditions are met. For the details of the\r\ndetection algorithm, interested readers can refer to our VirusBulletin presentation or the open-source package.\r\nFigure 4: Peak detection workflow (first execution where tables are initialized and peaks analyzed).\r\nIt is worth noting that telemetry data is dynamic, therefore the global benchmark as reflected by GST needs to be\r\nupdated over time. This is critical to maintain the accuracy of the peak analyzer over time. To make the global\r\nbenchmark adaptive, the analyzer uses a sliding window mechanism to quickly update the new GST using\r\nprevious GST and LST. This is to avoid re-calculating GST from scratch, thus greatly improving the performance\r\nof the algorithm. Figure 5 illustrates the process of updating the next global statistics table (denoted as GSTi+1) by\r\nusing the data stored in GST and LST from the previous execution (denoted as GSTi and LSTi, respectively).\r\nFigure 5: Subsequent executions updating LST and GST via a sliding window mechanism.\r\nEvaluation\r\nThis section comprises two parts: Peak Detection and Performance.\r\nIn this part, we selected four different peaks as representative of the efficacy of the tool.\r\nPhorpiex Peak\r\nPhorpiex is a botnet which is known to distribute a range of malware such as BitRansomware. There was a\r\nPhorpiex campaign launched on November 4, 2020. The telemetry peak analyzer successfully detected the\r\nhttps://blogs.vmware.com/security/2021/11/telemetry-peak-analyzer-an-automatic-malware-campaign-detector.html\r\nPage 4 of 10\n\nmalware campaign (see Figure 6) by detecting the surges from malicious Zip archive files from the telemetry data.\r\nThe campaign mainly targeted universities in APAC region.\r\nFigure 6: Phorpiex campaign detected by the surges from malicious Zip archive files.\r\nMore details on the Phorpiex campaign can be found in the report we published earlier: Phorpiex-Powered\r\nBitRansomware Targets APAC Universities.\r\nExcel 4.0 Peak\r\nLike VBA macros, Excel 4.0 (XLM) macros are a legitimate feature of Excel. These macros are increasingly\r\nabused by attackers to deliver a variety of malware families, such as Trickbot and Agent Tesla. The telemetry peak\r\nanalyzer successfully detected the malware campaign (see Figure 7) by detecting the surges from malicious\r\nencrypted Excel files in the telemetry data.\r\nFigure 7: Excel 4.0 and VelvetSweatshop campaigns detected by the surges from malicious\r\nencrypted Excel files.\r\nMore details on weaponized Excel 4.0 macros can be found in the reports we published earlier: Evolution of Excel\r\n4.0 Macro Weaponization and Evolution of Excel 4.0 Macro Weaponization – Part 2.\r\nVelvetSweatshop Peak\r\nVelvetSweatshop is a default encryption key stored in Microsoft Excel program code for decryption. Attackers\r\nleverage this trick to encrypt malicious Excel files in order to evade static-analysis-based detection systems, while\r\neliminating the need for a potential victim to enter a password. The telemetry peak analyzer successfully detected\r\nthe malware campaign (see Figure 7) by detecting the surges in encrypted Excel files from the telemetry data.\r\nMore details on the VelvetSweatshop campaign can be found in the report we published earlier: VelvetSweatshop:\r\nDefault Passwords Can Still Make a Difference.\r\nAnother Excel 4.0 Peak\r\nhttps://blogs.vmware.com/security/2021/11/telemetry-peak-analyzer-an-automatic-malware-campaign-detector.html\r\nPage 5 of 10\n\nRecently VMware TAU detected another Excel 4.0 wave attacking our customers. As Figure 8 shows, the\r\ntelemetry peak analyzer successfully detected surges from malicious Excel files in the telemetry data on October\r\n20, 2021.\r\nFigure 8: Excel 4.0 campaign detected by the surges from malicious Excel files.\r\nThe attacker leveraged highly obfuscated weaponized Excel 4.0 macros in the campaign. Figure 9 shows a code\r\nsnippet embedded in one of the samples from the campaign (MD5: aa6fb794bbba6766a1cfb2474dfc3729).\r\nFigure 9: Obfuscated malicious Excel 4.0 macros.\r\nhttps://blogs.vmware.com/security/2021/11/telemetry-peak-analyzer-an-automatic-malware-campaign-detector.html\r\nPage 6 of 10\n\nAs highlighted in the figure, the code contains a few obfuscated URLs. Further investigation reveals that the\r\nmacros attempted to download the very same payload from multiple URLs:\r\nhxxp://194.36.191[.]30/44489.4081978009.dat\r\nhxxp://23.106.122[.]40/44489.4081978009.dat\r\nhxxp://94.140.112[.]52/44489.4081978009.dat\r\nIt seems that the attacker chose to use multiple C2 hosts to increase their chances to download the payload in case\r\none or more hosts were taken down.\r\nExploring the sample and the URLs listed above on VirusTotal easily reveals similar samples and URLs from this\r\ncampaign, as shown in Figure 10.\r\nFigure 10: The correlation of indicators of compromise (IoCs) from this attack, created with\r\nVirusTotal Graph, visualizes the relationship between similar samples and the contacted hosts. The\r\nmeaning of each node on the graph can be found here.\r\nVMware NSX customers are well-protected against this kind of Excel 4.0-powered attacks. Figure 11 shows the\r\nanalysis overview from a controlled environment when executing the initial malware. As shown, VMware’s AI-driven NSX Advanced Threat Analyzer successfully detected a few high-risk artifacts, such as document\r\nexecuting regsvr32.exe, suspicious traffic, and potential social engineering attacks.\r\nhttps://blogs.vmware.com/security/2021/11/telemetry-peak-analyzer-an-automatic-malware-campaign-detector.html\r\nPage 7 of 10\n\nFigure 11: VMware NSX advanced threat analysis overview.\r\nCurrently, all the C2 URLs are not accessible. According to information shared by other researchers, the payload\r\n(MD5: aaf67a80f1dbb8406f14ca3f3af15ef7) is related to Qakbot (or Qbot), an infostealer that first surfaced as a\r\nbanking Trojan in 2007. It is not the first time that attackers leveraged malicious Excel 4.0 macros to deliver\r\nQakbot. Such attacks were also reported in February and May of this year.\r\nPerformance\r\nFigure 12 shows the execution time and the number of peaks found in one of our datacenters since the end of\r\nDecember 2020. The first interesting property is that the execution time grows linearly with the number of peaks\r\nfound, which is, in turn, proportional to the number of daily samples included in the time series (up to ≈ 4 million\r\nevents per day in our experiments).\r\nAs shown in the figure, the Telemetry Peak Analyzer never took more than 90 seconds to complete, even when the\r\nnumber of legitimate peaks (including those arising from benign files) approached 15. This demonstrates the\r\nproposed Peak Analyzer can handle data at scale.\r\nFigure 12: Processing times and identified peaks since end of December 2020.\r\nThe Open-Source Package\r\nThe Telemetry Peak Analyzer has become an open-source project:\r\nSource Code\r\nhttps://blogs.vmware.com/security/2021/11/telemetry-peak-analyzer-an-automatic-malware-campaign-detector.html\r\nPage 8 of 10\n\nhttps://github.com/vmware-labs/telemetry-peak-analyzer\r\nUsage\r\npython -m telemetry_peak_analyzer -n ${input_json} -s ${start_time} -e ${end_time}\r\nExample (from the repository root)\r\n1. Run to generate global statistics table (GST):\r\npython -m telemetry_peak_analyzer -n ./data/telemetry_example_3.json -s 2020-11-01 –e 2020-11-04\r\n1. Run to simultaneously detect peaks and update the GST (in production repeated daily):\r\npython -m telemetry_peak_analyzer -n ./data/telemetry_example_3.json -s 2020-11-04 –e 2020-11-05\r\nThe outputs from 1st run and 2nd run are shown in Figure 13 and Figure 14, respectively.\r\nFigure 13: Example output from 1st.\r\nFigure 14: Example output from 2nd run.\r\nConclusion\r\nIt is important to identify hidden yet valuable information in threat telemetry data, such as detected malware\r\ncampaigns and the customers and sectors that were affected the most. The proposed telemetry peak analyzer is\r\ndesigned to handle such composite time series telemetry data to effectively detect malware campaigns at scale, as\r\ndemonstrated in the Evaluation part.\r\nAs part of future improvements, we plan to extend our prototype to process threat labels as well as dynamic\r\nbehaviors. Currently we have separate peak analyzer instances running across different regions and feeds. In the\r\nfuture, we also plan to merge the state of the instances. As an open-source project, we encourage the open-source\r\ncommunity to share feedback and help improve the project over time.\r\nhttps://blogs.vmware.com/security/2021/11/telemetry-peak-analyzer-an-automatic-malware-campaign-detector.html\r\nPage 9 of 10\n\nSource: https://blogs.vmware.com/security/2021/11/telemetry-peak-analyzer-an-automatic-malware-campaign-detector.html\r\nhttps://blogs.vmware.com/security/2021/11/telemetry-peak-analyzer-an-automatic-malware-campaign-detector.html\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blogs.vmware.com/security/2021/11/telemetry-peak-analyzer-an-automatic-malware-campaign-detector.html"
	],
	"report_names": [
		"telemetry-peak-analyzer-an-automatic-malware-campaign-detector.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434587,
	"ts_updated_at": 1775791216,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d03a8439eae2ebedd71e3fc95334ce464b7a35e0.pdf",
		"text": "https://archive.orkl.eu/d03a8439eae2ebedd71e3fc95334ce464b7a35e0.txt",
		"img": "https://archive.orkl.eu/d03a8439eae2ebedd71e3fc95334ce464b7a35e0.jpg"
	}
}