November 1, 2026
I Passed TCM Security’s PMRP: My Review of the Course, Exam, and Malware Analysis Workflow
I recently passed TCM Security’s Practical Malware Research Professional (PMRP) certification, and I wanted to share my experience with the…
By seif
15 min read
I recently passed TCM Security's Practical Malware Research Professional (PMRP) certification, and I wanted to share my experience with the course and exam, along with the malware analysis workflow I developed throughout the process.
I'll also discuss where I think the training could be expanded, particularly with the growing role of AI in malware analysis.
But first, some context on why I decided to pursue this certification in the first place.
Preface: Why I Took the PMRP
My primary interests in cybersecurity are digital forensics, incident response (DFIR), and threat hunting.
Throughout my learning and practical experience in DFIR, one area I've consistently identified as a weakness is malware analysis and reverse engineering.
I could investigate suspicious process execution, analyze Windows artifacts, reconstruct attack timelines, and identify indicators of compromise. But whenever an investigation required a deeper understanding of an unfamiliar executable, script, or payload, I wasn't nearly as confident.
I understood the general concepts behind malware analysis and knew some of the tools. What I lacked was a proper, repeatable methodology.
More specifically, I didn't have a solid workflow for approaching unfamiliar malware in a professional setting.
Where should I start? What can basic static analysis tell me? When should I move to dynamic analysis? At what point is reverse engineering necessary? How do I know when I've gathered enough evidence? And most importantly, how do I translate those findings into something useful for an incident response investigation?
These were the gaps I wanted to address.
I wasn't necessarily looking to become a full-time malware reverse engineer. Rather, I wanted to become a more capable DFIR analyst who could independently investigate suspicious files, understand their behavior, and explain their relevance to a broader intrusion.
That's what led me to TCM Security's PMAT course and PMRP certification.
My biggest takeaway from this experience wasn't simply learning how to use more malware analysis tools. It was developing a structured approach to malware investigation that I can continue building upon.
And if you're coming from a similar SOC, DFIR, or threat hunting background, I think that's one of the most valuable things you can take away from this training as well.
One caveat before we get into it: this is a starting point, not the finish line. While PMAT provides a strong foundation, going deeper into malware reverse engineering requires significantly more practice and dedicated study. I'll talk about that later, including other resources such as Invoke RE.
1. The Course: Practical Malware Analysis & Triage (PMAT)
The certification is supported by TCM Security's Practical Malware Analysis & Triage (PMAT) course, created by Matt Kiely, also known as HuskyHacks.
First of all, I really enjoyed this course.
One thing I appreciate about TCM Security's training is its emphasis on actually doing things rather than simply memorizing terminology or watching demonstrations.
PMAT follows that philosophy pretty well.
The course begins with setting up a safe malware analysis environment, including FLARE-VM, REMnux, and network simulation tools such as INetSim. From there, it introduces different approaches to understanding suspicious files.
You work through basic static and dynamic analysis before moving into more advanced areas such as assembly language, reverse engineering, debugger-assisted analysis, scripting, anti-analysis techniques, and malware written in different languages.
It also covers shellcode analysis, .NET malware, Go binaries, automated triage, YARA rules, and reporting.
That's a considerable amount of material for a relatively compact course.
What I liked most
What stood out to me was that the course wasn't overly focused on one tool or one particular way of analyzing malware.
Basic static analysis teaches you to examine metadata, strings, imports, and other file properties without executing anything.
Dynamic analysis introduces the other side of the investigation: observing what the malware actually does inside a controlled environment.
Advanced static analysis takes you deeper, examining program logic through disassembly and decompilation.
The real value is learning how these approaches complement one another.
A suspicious API import might suggest that a binary can create processes, but that doesn't necessarily mean it does so during execution. A hardcoded URL might look like a command-and-control indicator, but understanding how it is used requires additional analysis.
The course helps establish that distinction.
For someone like me who was looking to build an actual methodology rather than simply learn a collection of tools, this was particularly valuable.
I also appreciated the inclusion of reporting and YARA rule development.
In DFIR, being able to understand malware is important, but being able to translate that understanding into actionable findings is arguably just as important.
Your analysis needs to help someone else investigate, scope, hunt, contain, or remediate an incident.
Where I think the course could improve
I think PMAT is an excellent foundation, but I wouldn't treat it as a complete education in malware reverse engineering.
Some of the advanced topics are necessarily covered at an introductory level.
If you're expecting to become proficient in assembly language, unpacking sophisticated malware, or reversing complex native binaries from this course alone, you'll need substantially more practice.
There's also a difference between following a guided demonstration and independently investigating an unfamiliar sample.
The latter requires considerably more judgment, troubleshooting, and research.
Still, I think the course does a good job of preparing you to begin developing those skills.
My recommendation would be to take the labs seriously, reproduce the techniques yourself, and spend additional time investigating samples without following a walkthrough.
And don't just memorize where to click in Cutter, x32dbg, or dnSpy. Understand what you're actually trying to establish.
The tools will change. The analytical concepts are what you want to retain.
2. The PMRP Exam: How Was It?
The PMRP certification is a fully practical assessment.
TCM Security provides five days for malware analysis and an additional two days to complete and submit a professional report.
There are no multiple-choice questions. You're expected to investigate malware, document your findings, and develop detection rules.
I really like this format.
It places much more emphasis on demonstrating technical competence and communicating results than simply remembering facts.
Difficulty and overall experience
I found the exam very challenging, but in a good way.
The individual concepts aren't necessarily beyond what the course introduces. The real challenge comes from applying those concepts independently, deciding which tools are appropriate, and knowing when you've gathered enough evidence.
Not every file benefits from the same investigation process.
Sometimes static analysis immediately tells you a great deal about a program's capabilities. Other times, you need to dig into the control flow, decode an embedded payload, or investigate why the observed behavior doesn't match your initial hypothesis.
I think this is where the exam succeeds.
It forces you to think like an analyst rather than simply follow a checklist.
It also made me appreciate that malware analysis is as much about knowing what to investigate next as it is about knowing how to use the tools.
You could spend hours disassembling functions that aren't relevant to the sample's core behavior. Conversely, relying entirely on automated results could cause you to miss important functionality.
Finding the right balance is part of the challenge.
The reporting requirement
This was probably one of the most time-consuming aspects of the entire experience.
My final report was around 167 pages, including analysis, evidence, detection rules, and supporting documentation.
That sounds excessive, and I don't think page count should ever be treated as a measure of report quality.
But the exercise reinforced something important: documenting malware correctly takes time.
You need to explain what the sample does, support your conclusions with evidence, and present everything in a way that another analyst can follow.
I structured my analysis around static analysis, advanced static analysis when applicable, dynamic analysis, indicators of compromise, and detection opportunities.
Screenshots were used to support specific findings rather than simply demonstrate that a tool had been opened.
I also consciously tried to avoid making claims that weren't supported by evidence.
If the code indicated a capability but I couldn't successfully observe it during execution, I would distinguish between what static analysis established and what dynamic analysis confirmed.
That distinction is essential in professional malware reporting.
In a real investigation, you're not simply reverse engineering a binary for yourself. Someone else may need your findings to scope an intrusion, hunt across endpoints, or make containment decisions.
3. The Malware Analysis Workflow I Developed
This is probably the most valuable takeaway I got from the certification.
One of my original reasons for taking PMRP was that I didn't have a proper methodology for malware analysis.
I knew individual tools and techniques, but I didn't always know how to put them together into an efficient investigation.
Initially, it can be tempting to throw every tool you have at a sample and see what happens.
That becomes inefficient pretty quickly.
Over time, I settled into a workflow that prioritized initial triage, hypothesis development, targeted investigation, and evidence collection.
This isn't intended to be a comprehensive malware reverse engineering methodology or a replacement for more advanced analysis techniques.
Rather, it's a practical starting workflow for SOC and DFIR analysts who need to investigate suspicious files and produce actionable findings.
Here's how I currently approach it.
Step 1: Initial file identification and triage
I begin by identifying the actual file type, calculating hashes, inspecting metadata, and checking for obvious indicators of packing, obfuscation, or unusual characteristics.
Some of my go-to tools are Detect It Easy (DiE), PEStudio, FLOSS, and standard hashing utilities.
For scripts and other non-PE formats, I adapt the initial inspection accordingly.
The objective isn't to understand everything immediately. It's to establish what kind of file I'm dealing with and where my investigation should go next.
Step 2: Form initial hypotheses
Next, I examine relevant strings, imports, and other static indicators to identify possible capabilities.
Could this be a downloader? Does it appear to implement persistence? Is it using networking APIs? Could there be an embedded second-stage payload?
These are hypotheses, not findings.
I use them to guide the next steps rather than treating them as established behavior.
Step 3: Perform targeted static analysis
This is where I choose tools based on the file type and the questions I need to answer.
For native executables, Cutter or another disassembler can help identify functions and reconstruct important control flow.
For .NET assemblies, dnSpy is particularly useful because of how much original program structure can often be recovered.
For obfuscated scripts, I prefer working through the decoding process with small, controlled Python scripts rather than executing the original code unnecessarily.
I also try to focus on functions that explain core capabilities instead of attempting to reverse engineer every line.
Step 4: Conduct controlled dynamic analysis
When appropriate, I execute the sample in an isolated analysis environment with monitoring already configured.
Tools such as Process Monitor, Process Hacker, TCPView, Wireshark, and INetSim help me observe process execution, file modifications, registry activity, and network communications.
This is also where I validate the hypotheses formed during static analysis.
An important lesson here is to understand your own lab environment. Simulated HTTP responses and fake services can affect the behavior you observe, so not every successful connection or download tells you what you initially think it does.
Step 5: Correlate static and dynamic findings
I try not to treat static and dynamic analysis as completely separate exercises.
If dynamic analysis reveals an unexpected process or registry modification, I'll return to the code to understand how it was triggered.
Similarly, if static analysis reveals suspicious functionality that didn't execute, I'll investigate the relevant conditions or branches.
Debugger-assisted analysis becomes useful when those questions require controlling program execution.
The objective is to build a coherent explanation of the malware's behavior.
Step 6: Extract indicators and develop detections
Once I understand the important functionality, I document relevant host and network indicators.
I also develop YARA rules where appropriate, focusing on characteristics that are sufficiently distinctive to the sample.
This requires some care.
A rule that matches a particular malware sample isn't automatically a good detection rule. It should also be tested against benign files where possible, and its limitations should be understood.
I think malware analysis should naturally feed into detection engineering rather than end with a list of extracted strings.
Step 7: Document findings throughout the investigation
This was perhaps the most useful workflow improvement I made.
Instead of completing all the analysis and writing the report afterward, I began documenting important findings and capturing evidence as I went.
That reduced the amount of time spent retracing steps and trying to recreate screenshots.
It also forced me to evaluate whether I actually had enough evidence to support a statement.
I now think of reporting as part of the investigation itself, not simply the last task before submission.
A note on this workflow
This is the approach I developed for the scope of the PMRP exam, and I believe it provides a solid starting point for analysts who are relatively new to malware analysis.
But real-world malware investigations aren't always this straightforward.
You may encounter packed or virtualized binaries, sophisticated anti-analysis techniques, kernel-mode components, multi-stage loaders, or samples that require extensive debugging and reverse engineering just to recover their underlying functionality.
Some investigations also require memory forensics, sandbox instrumentation, custom tooling, or a deeper understanding of operating system internals.
The workflow gives you a way to approach the problem systematically. It doesn't guarantee that every sample can be fully analyzed using the same set of tools.
And that's exactly why I view PMRP as a starting point rather than a final destination.
4. A Major Caveat: Malware Analysis Has Changed With AI
This is one area where I think the PMAT curriculum could benefit from additional material.
To be clear, the course does include a lesson on advanced script analysis using ChatGPT, and the fundamentals it teaches remain relevant.
But much of its core approach was developed before the more recent advances in large language models, AI-assisted reverse engineering, and agentic analysis workflows.
By 2026, the role AI can play in malware analysis has expanded considerably.
And I think anyone learning malware analysis today should at least understand how to incorporate these capabilities responsibly.
How I'd use AI in malware analysis
Personally, I find AI most useful as a research assistant and productivity multiplier.
For example, when examining a large decompiled function, an LLM can help explain unfamiliar code patterns, identify relevant Windows APIs, and suggest possible interpretations of control flow.
For heavily obfuscated scripts, AI can help scaffold small Python utilities to decode strings, decompress data, or extract embedded files.
It can also help review YARA rules, organize notes, and improve the clarity of technical explanations.
These are valuable time savings.
The important part is that AI-generated explanations aren't evidence.
If an LLM claims a function establishes persistence, I still need to verify that behavior in the code or through controlled execution.
If it suggests that a Base64 string decodes to a particular URL, I want the actual decoded bytes, not a plausible-looking interpretation.
This is especially important with low-level code, where an incorrect assumption about a branch condition, pointer, or calling convention can completely change the conclusion.
AI-powered malware analysis is already becoming a real workflow
Google's security research teams have published work on using Gemini to analyze malware at scale, including pipelines that combine unpacking, decompilation, and AI-assisted interpretation.
They've also demonstrated how code execution and threat intelligence integrations can help models decode obfuscated information and enrich suspicious indicators.
Google Threat Intelligence's Code Insight has continued expanding its supported file types and investigative capabilities, including LNK analysis and agentic investigative workflows in 2026.
These developments are worth paying attention to.
They demonstrate that AI is moving beyond simply summarizing suspicious code toward helping automate portions of a malware research pipeline.
Of course, that introduces new risks as well.
Models can hallucinate, misinterpret control flow, and generate convincing explanations that aren't supported by the underlying sample.
There are also confidentiality considerations when sending potentially sensitive binaries, internal artifacts, or investigation data to third-party services. Malware content itself should be treated as untrusted input, including when AI agents are involved.
For me, the correct approach is to use AI to accelerate investigation while keeping the analyst responsible for verifying the results.
What I would add to the PMAT course today
If I were updating the curriculum, I'd love to see a dedicated section focused on modern AI-assisted malware analysis.
Not a lesson on asking ChatGPT whether a file is malicious, but an actual workflow demonstrating how to combine conventional analysis with AI-assisted tooling.
For example, I would cover how to feed selected decompiled functions into an LLM with the correct context, how to build small decoding utilities safely, how to integrate threat intelligence lookups, and how to verify model-generated explanations against disassembly or runtime observations.
I'd also include the limitations of AI-assisted reversing, handling prompt injection embedded in malicious content, and the risks of submitting samples to public AI services.
Finally, it would be useful to demonstrate a small, reproducible automation pipeline that performs triage, extracts relevant information, assists in interpreting suspicious functions, and generates a preliminary report for analyst review.
I think that would complement the existing course very well.
The goal shouldn't be to replace traditional malware analysis education.
It should be to teach analysts how to combine those skills with the capabilities that are becoming increasingly available.
5. Is PMRP Enough to Learn Malware Reverse Engineering?
This is an important distinction I want to make.
**PMRP gives you a foundation in malware analysis. **It does not make you a reverse engineer overnight.
And I don't think that's a criticism of the certification. It's simply a matter of scope.
Malware analysis and reverse engineering are enormous fields. You can spend years working on native code, assembly language, debugging, unpacking, memory analysis, and operating system internals and still regularly encounter unfamiliar techniques.
For my particular goals in DFIR, PMAT gave me what I was looking for: a structured methodology and the confidence to begin approaching unfamiliar samples independently.
But I also recognize that there's a significant difference between performing initial malware triage and being able to reverse engineer sophisticated malware families at a deep technical level.
Where to go after PMRP
If you want to continue developing those skills, I think the natural next step is to move toward more specialized reverse engineering training and increasingly difficult real-world samples. Keep in mind I am taking from the advice from my mentors and peers who specialize in malware reversing/development.
One resource worth exploring is Invoke RE, which offers malware analysis and reverse engineering courses.
Its Introduction to Malware Binary Triage (IMBT) course focuses on investigating real-world malware through binary analysis, while Advanced Malware Binary Triage (AMBT) goes deeper into anti-analysis techniques, more complex malware, and automation methodologies.
For anyone pursuing deeper specialization, SANS FOR610 and the associated GIAC Reverse Engineering Malware (GREM) certification are also worth considering.
Beyond formal training, I think the most important thing is continued independent practice.
That means working with real-world malware in an appropriate isolated environment, reading published research, studying assembly and operating system internals, reproducing other researchers' findings, and gradually taking on samples that require more sophisticated techniques.
You also need to become comfortable not immediately understanding everything you're looking at.
There will be functions you can't explain, protections you don't know how to bypass, and samples that require far more time and research than anticipated.
That's part of developing the skill.
For me, PMRP is not the conclusion of my malware analysis learning. It's the point where I finally feel I have a foundation and a clear direction for going deeper.
6. Would I Recommend the PMRP?
Yes, particularly for people coming from SOC, DFIR, or threat hunting backgrounds who want a practical introduction to malware analysis.
If you're in a similar position to where I was before taking the course, where you understand security investigations but aren't confident investigating unfamiliar malware, I think PMAT and PMRP are worth considering.
You'll learn the tools, but more importantly, you'll start developing a methodology for approaching suspicious files.
That methodology is what I found most valuable.
It's also useful for people interested in eventually moving toward dedicated malware analysis or reverse engineering roles, provided they understand that more specialized training will be necessary.
I wouldn't recommend approaching this certification as simply another credential to add to a résumé.
The real benefit comes from learning how to investigate unfamiliar code, verify suspicious behavior, and communicate the results.
And if you're preparing for the exam, spend time practicing independent analysis and professional reporting, not just watching all the course content.
Being able to explain what a tool does is not the same as being able to use it to answer an investigative question.
7. Final Thoughts and Thanks
Overall, I'm very happy I decided to pursue the PMRP.
I started this because I recognized a weakness in my DFIR skill set.
Malware analysis and reverse engineering were areas where I didn't have a proper foundation, and I wanted to change that.
I wouldn't claim to have mastered either discipline after completing one course and certification.
But I did come away with something I was previously missing: a repeatable workflow, a better understanding of how different analysis techniques complement one another, and more confidence in approaching unfamiliar samples.
I became more comfortable moving between static and dynamic analysis, understanding unfamiliar code, writing small analysis utilities, identifying host and network indicators, and translating technical findings into a structured report.
I also developed a better appreciation for the limitations of my own analysis.
Not every suspicious function proves malicious behavior, not every extracted string is meaningful, and not every runtime observation tells the whole story.
Those are lessons I intend to carry into my work in DFIR and threat hunting.
A huge thank you to Matt Kiely (HuskyHacks) for creating Practical Malware Analysis & Triage. I really enjoyed the course and appreciated the effort put into making malware analysis approachable without reducing it to purely theoretical material.
And thank you to TCM Security for putting together an assessment that emphasizes hands-on investigation, reporting, and detection development.
I'm glad to have passed, but more importantly, I'm glad I addressed a weakness that I had been aware of for some time.
There's still a considerable amount I want to learn, particularly in more advanced malware reverse engineering, anti-analysis techniques, and modern AI-assisted malware research.
For now, though, I have a much stronger starting point.
The certification is a milestone. Building the skills to become a better DFIR analyst is the real goal.