Normal view

There are new articles available, click to refresh the page.
Before yesterdayMain stream

Bitcoin Whales Keep Buying Through Volatility As Retail Steps Away

22 January 2026 at 21:00

Bitcoin is facing renewed volatility after a sharp drop from the $97,000 region to nearly $87,000 in just a few days, shaking market confidence and forcing bulls into defense mode. The pullback comes as geopolitical tension between the United States and the European Union escalated this week, with trade-war rhetoric returning to the spotlight and uncertainty rising around potential retaliatory measures tied to broader disputes, including the situation surrounding Greenland.

Despite the downside pressure, on-chain behavior suggests the market structure is not collapsing, but shifting. Since January, Bitcoin whales have continued to accumulate through corrective phases, absorbing spot supply even as price action weakened.

At the same time, retail investors appear to be stepping back after the drawdown, reducing activity and participation across the market. This divergence highlights a familiar dynamic: short-term fear tends to push smaller traders out, while larger holders use volatility to build exposure at discounted levels.

With price now stabilizing near a major psychological zone, Bitcoin is entering a critical stretch where demand must return to confirm whether this move was a temporary shakeout or the start of deeper weakness.

Whales Keep Accumulating as Bitcoin Fights to Hold $90K

Bitcoin is now attempting to hold above the $90,000 level as volatility remains elevated and traders look for signs of stabilization after the recent swing lower. Price action has become increasingly reactive to macro headlines, and the $90K zone is acting as a key psychological threshold that could determine whether the market consolidates or extends the correction.

In this environment, short-term sentiment can flip quickly, especially as liquidity thins and intraday moves become sharper across both spot and derivatives markets.

However, a CryptoQuant report suggests the underlying structure has not broken down. Even after geopolitical risks intensified and broader risk appetite deteriorated, whale holdings have not declined on a monthly basis.

Instead, large holders have continued increasing exposure, reinforcing the view that the current phase reflects structural accumulation rather than broad distribution. This matters because sustained whale buying during drawdowns typically implies supply is being absorbed at lower levels, reducing the probability of a cascading sell-off driven purely by spot sellers.

Bitcoin Total Whale Holdings | Source: CryptoQuant

In practical terms, the market has shaken, but whale conviction has not. While retail participants often reduce exposure during periods of uncertainty, larger investors tend to operate with longer time horizons, stepping in when volatility forces weak hands out.

If this accumulation trend persists, it can help establish a stronger base below price and create conditions for a more stable recovery once demand improves. For now, Bitcoin’s next move depends on whether $90K holds under continued macro pressure.

Price Action Details: Consolidation Continues

Bitcoin is attempting to stabilize near the $90,000 level after last week’s volatility sent price sharply lower from the prior range above $100,000. The weekly chart shows BTC holding a higher-low structure since the November breakdown, but momentum remains fragile as sellers continue to defend overhead resistance zones. After reclaiming the mid-$80,000s, price pushed back toward $90,000, yet the latest weekly close suggests hesitation and a lack of strong follow-through from buyers.

BTC testing key demand level | Source: BTCUSDT chart on TradingView

From a trend perspective, BTC is trading below the short-term moving average, which has rolled over and now acts as dynamic resistance. The rebound has been constructive, but it remains corrective until the price can break and hold above that blue trend line. Meanwhile, the longer-term averages are still rising, reflecting that the broader cycle is not broken, but that the market is transitioning into a slower consolidation phase.

Volume also confirms this uncertainty. Sell-side spikes marked the initial breakdown, while recent recovery candles have not shown the same level of aggressive demand. For bulls, holding the $88,000–$90,000 zone is critical to prevent a deeper pullback. A clean weekly close above $92,000 would improve the short-term outlook and open the door for a stronger recovery leg.

Featured image from ChatGPT, chart from TradingView.com 

Bitcoin Volatility Signals Potential Move: Bullish Breakout Or A Deeper Correction?

13 January 2026 at 20:00

Bitcoin is pressing above the $92,000 level after an eventful start to 2026 marked by intensified geopolitical and political developments. In early January, the United States launched a military operation in Venezuela, resulting in the capture of President Nicolás Maduro and significant upheaval in regional politics and energy markets. This action formed part of a broader US campaign against illicit networks and pressure on Caracas, with implications for global oil flows and uncertainty in macroeconomic sentiment across markets.

Simultaneously, tensions between Federal Reserve Chair Jerome Powell and US President Donald Trump over monetary policy and institutional independence have added another layer of volatility. In a rare and pointed statement, Powell framed the situation as a direct consequence of central bank independence, saying: “The threat of criminal charges is a consequence of the Fed setting rates based on our best assessment of what will serve the public, rather than following the preferences of the President.”

Despite these headline risks, Bitcoin’s price action has entered a period of calm, with realized volatility compressing to historically low levels. Such low-volatility regimes typically reflect a temporary balance between supply and demand.

In past cycles, extended calm like this has often preceded periods of significant volatility and range expansion, as accumulated imbalances resolve with sharp directional moves. This sets the stage for a potentially decisive breakout as participants await clearer catalysts while price hovers near the critical $92K threshold.

Volatility Compression Signals A Market Near Inflection

A recent analysis by Axel Adler highlights a critical shift in Bitcoin’s market structure: realized volatility has compressed to 23.6%, placing it near the lower end of this cycle’s historical range. Rather than signaling direction, this drop in volatility reflects a market that has temporarily lost momentum, with price swings narrowing and impulse strength fading. In past cycles, similar conditions have rarely persisted for long.

From a structural standpoint, this environment suggests that Bitcoin is in a classic compression phase. As volatility contracts, underlying imbalances between supply and demand tend to build quietly beneath the surface. When these imbalances reach a tipping point, price typically transitions from stability into expansion—often abruptly.

Bitcoin 30-day Price High and Low All Time | Source: CryptoQuant

This view is reinforced by Bitcoin’s 30-day high–low range. The gap between recent rolling highs and lows continues to tighten, confirming that price is coiling within an increasingly narrow band. Both intraday and multi-day fluctuations have diminished, and neither buyers nor sellers have been able to assert sustained control.

Historically, breakouts from such compressed ranges tend to attract algorithmic and trend-following capital, amplifying follow-through once price escapes the range. While this setup does not guarantee an upside or downside resolution, it does suggest that the probability of a decisive move is rising. With volatility and range metrics aligned, Bitcoin appears to be approaching a moment where consolidation gives way to renewed directional conviction.

Bitcoin Price Reclaims $92K as Structure Slowly Improves

Bitcoin is attempting to reclaim the $92,000 level after several weeks of consolidation following the sharp November drawdown. On the daily chart, price has formed a clear base in the $86K–$88K region, where aggressive selling pressure was previously exhausted. Since then, BTC has printed a sequence of higher lows, signaling a gradual shift from distribution into short-term accumulation.

BTC testing critical demand level | Source: BTCUSDT chart on TradingView

The recent push above the descending short-term moving average reflects improving momentum, although the broader structure remains mixed. Price is still trading below the declining mid-term trendline and well under the longer-term moving averages, which continue to act as overhead resistance near the $98K–$105K zone. This suggests that, while downside pressure has eased, Bitcoin has not yet re-entered a strong bullish trend.

Volume remains relatively muted during the rebound, indicating that the move is driven more by reduced selling than by aggressive new demand. This aligns with a market transitioning into stabilization rather than immediate expansion. The $92K area now represents a critical pivot: holding above it would confirm acceptance at higher levels and open the door for a broader range rotation toward $96K–$100K.

Failure to sustain this breakout, however, would likely keep BTC trapped in a consolidation range, with downside risk returning toward the $88K support. For now, price action suggests cautious recovery rather than trend reversal.

Featured image from ChatGPT, chart from TradingView.com 

Stablecoins: Evolution, not a Revolution

23 December 2025 at 11:11

Bitcoin Magazine

Stablecoins: Evolution, not a Revolution

Technologies tend to have a natural ceiling built into their utility and popularity. Once they’ve solved all the problems they can solve, their growth is effectively capped. As soon as all potato fans own a potato peeler, the peeler market’s growth potential is largely tapped out. Indeed, the big question around AI at the moment is how many problems it will be able to solve. The market could already be overblown, or it could be practically limitless.

What about stablecoins? They’ve grown from practically nothing at the turn of the decade to a market cap in the mid-12 digits and monthly transaction volumes in excess of $1 trillion. Citigroup expects the aggregate stablecoin market cap to hit around $2 trillion by the end of the decade. 

If we’re talking trillions, it sounds much more like AI than potato peelers.

But do stablecoins have a natural limit? Is their utility restricted to a certain range of problems? If so, where is it? How far can stablecoins grow, and what might stop them?

In order to find answers to these questions, let’s recall why stablecoins have come so far already, what will limit their future growth, and what that means for their overall utility, i.e. the range of problems they can solve.

Why Stablecoins Gained Market Traction

Three reasons for stablecoins’ current popularity stand out.

Stable Prices, Low Volatility

The first reason is price stability. Many cryptocurrencies are volatile, which makes them valuable for speculation but awkward to use as everyday currencies. The value of stablecoins is, well, stable. By definition. Price stability is their fundamental value proposition.

Price stability is also arguably an advantage relative to other cryptocurrencies whose value is perpetually expected to rise. If your coins’ value will double in five years, you might be reluctant to spend them now. But if your coins will be worth the same or even a little less in five years, you better spend them before they burn a hole in your pocket.

Greater Portability 

The second is portability. Exchanging fiat for crypto can be arduous, but exchanging one crypto for another is usually much easier. So many users find it more efficient to convert fiat into stablecoins in bulk, then easily shift value between various cryptocurrencies as needed. USDT is the most traded coin overall because it works so well on the other side of any crypto trade.

In many markets, these first two factors reinforce each other. Many countries’ national currencies depreciate more rapidly than stablecoins’ pegged currencies, so stablecoins give people in those countries a way to protect their wealth from depreciation. And those same countries often use currency controls to prevent capital flight, but their citizens can often access stablecoins to circumvent those artificial barriers.

Tax Optimization

The third reason is simply taxes. Many jurisdictions — including the United States, Canada, the United Kingdom, Japan, and Australia — classify cryptocurrencies as commodities rather than currencies. As a result, capital gains taxes apply to cryptocurrency price appreciation, so each transaction can be a taxable event. But many users and businesses might want to use crypto for its portability, like payment rails, so stablecoins’ price stability helps them avoid taxable events during routine payments.

You Can’t Copy State Money without State Rules

Fiat currency is the modern state’s crown jewel. Beyond a national currency’s symbolic value, controlling the source of everyone’s money is a very advantageous position. For an impression of what a big deal this can be, rewatch Ridley Scott’s Black Rain (it’s a great rewatch for any reason, not least of which is Michael Douglas rockin’ a killer mullet). 

If stablecoins are minting hundreds of billions of fiat equivalents and moving trillions in value each month, the state is going to take a very close interest in what they’re doing and how. You can’t open your own private mint moving that kind of liquidity and hope to stay under the regulatory radar.

Besides, history shows that states will regulate whatever they can. They have to. Any activity they cannot regulate implicitly threatens their claim to authority, and they don’t actually produce anything (besides perhaps regulation), so they need to acquire resources. In order to take their cut from an activity, states have to first quantify and control (i.e. regulate) that activity. This is the kind of argument that led Charles Tilly, one of the last century’s most respected historical sociologists, to call states “protection rackets” and “organized crime.”

Centralized activity is also why states preferred tariffs over taxes until pretty recently. Back when bureaucracies were small and populations were spread out, states found it very hard to tax income. They didn’t have the data to quantify it nor the technology to control it. So they preferred tariffs because there are far fewer ports and bridges than there are households and shops. 

In other words, the more centralized an activity is, the easier it is to quantify and control (and skim of course). More concisely: centralization attracts regulation. And the more central an activity is to state power, the more incentive the state has to regulate it, and printing money is about as central as it gets.

Stablecoins are no exception. They are centralized both in terms of the source of their value and in their actual operations, which is why regulators have been busy churning out rules lately. While that regulation might even be necessary and wise, it does and will limit stablecoins’ utility.

Rules, Their Effects, and Extrapolating the Future

The supply of regulation has increased a lot recently, but maybe it’s just meeting demand. In fact, Tether and Circle, the two biggest stablecoin issuers, are getting involved in the regulatory process with different strategies. They’re aware of their position as private USD mints and companies that take large amounts of private deposits and reinvest them (i.e. banks). Mature stablecoin issuers seem to want regulation.

The regulators themselves argue that stablecoin regulation is a good thing because it protects users and gives issuers “more predictable regulatory environments.” Not surprisingly, this is the view of the SEC. 

And this reasoning is not without merit. Companies managing hundreds of billions in liabilities should be able to meet those liabilities, and maybe someone should check. But the existing regulations have added some massive obstacles to where and how people can use stablecoins.

Let’s start with Europe, because regulatory legalese is the EU’s official language. The Markets in Crypto-Assets Regulation (MiCA) is the key stablecoin regulatory measure in Europe. It became law in 2023, but the consequences only really struck in Q1 2025. Since MiCA requires stablecoin issuers to obtain an e-money license in at least one European state, major exchanges like Binance and Coinbase delisted nine leading stablecoins, including USDT, the biggest stablecoin of all. (Of course, a consortium of nine too-big-to-fail European banks is trying to launch their own euro-pegged stablecoin.) 

MiCA was a regulatory nuke, practically banning leading stablecoins and seeking to replace them with astroturfed European alternatives.

Somewhat more friendly to experimentation and innovation, the USA has implemented the Guiding and Establishing National Innovation for U.S. Stablecoins (GENIUS) Act. GENIUS is a little more permissive in that the Treasury Department can determine that foreign stablecoin issuers are subject to sufficient regulation at home, sparing them the need for a local US presence. It also prescribes a few particulars like reserve requirements and public disclosure. 

While the GENIUS Act formally restricts issuers and protects users, it also makes issuers subject to the Bank Secrecy Act to prevent money laundering. As anyone knows who’s ever bought crypto on an exchange, AML and KYC are significant friction, and they effectively restrict how holders can use stablecoins. Eliminating exactly that friction was one of the features that made stablecoins attractive in the first place. Greater consumer protection might increase stablecoins’ utility in the long-term aggregate, but a user who wants to buy and trade USDT right now might disagree.

And while the EU and the USA are arguably the most important markets for stablecoins, many other markets either have regulations in place (e.g. Japan, Canada, Chile) or in the pipeline (e.g. the UK, China, Australia, Brazil, Turkey). 

Imagine a giant Venn diagram of all these regulatory regimes, and stablecoins’ utility is in the space where they all overlap and the activity remains economical. How big is that space? And given that stablecoins are pegged to national currencies, which national administrations guard jealously, are these already diverse regulatory regimes likely to converge or diverge in the future?

The denser the jungle of regulations, the smaller and more isolated the clearings where stablecoins can flourish. They will still have a niche, but some niches are more niche than others. It’s unlikely that any stablecoin, based on a national or even regional fiat currency, will satisfy all the regulators in all the markets necessary to become a global currency. That’s probably why real-world stablecoin usage ends up being far more geographically constrained than the “global digital dollars” many hoped for. Even USDT, the most widely used stablecoin, operates at scale in only a few permissive jurisdictions. With roughly 40% of USDT’s market cap and an effectively identical product, USDC faces the same structural limits.

Good as Far as They Go, but Bitcoin Can Go Farther

So stablecoins are centralized fiat tokens. Being centralized and tethered to state fiat means that regulators are grasping them tightly, resulting in cost and friction for everyone involved. This process is already well underway and will continue. Does this mean that stablecoins are doomed?

Probably not. As tokenized fiat, stablecoins are likely to thrive wherever fiat is good enough. In practice, that means conventional payments. I recently defined payments as instructions to clear a debt. Wherever an intermediated quid pro quo describes the interaction, stablecoins will probably work as the quid. Indeed, the potential to capture some of the payment business from other fintech solutions (or to defend their own) is probably why established fintech players like Klarna, PayPal, and Stripe have launched their own stablecoins or stablecoin accounts. Stablecoins are turning into normal payment fintech, but maybe just normal payment fintech.

Normal means subject to state regulations and the functional and geographic limits they impose. It means juicy fees going to intermediaries. It means friction for users. 

But there is a whole universe of value that eludes the payment model either because it requires direct, disintermediated transfers, it disregards political geography, there is no debt involved, or all of the above. The potential for value transfer is sometimes hard to see because the balkanized, intermediated payment paradigm is so dominant. We’ve simply lacked the technology to do much else until recently.

Still, whenever you toss some coins to a busker or tip a content creator, you’re pushing value, not clearing debt. Whenever cash moves from hand to hand, the transfer is disintermediated. Now imagine the busker is on the other side of the globe, and you discovered them through an app. The key to perceiving the rest of that value-transfer universe is to bring that directness and borderlessness into our digital world.

Value transfer needs less friction than fiat in both a technical and regulatory sense. But to achieve that, you’d need a currency that is detached from national currencies and decentralized. That’s where bitcoin comes in. Bitcoin is an open, decentralized, neutral monetary network that works for anyone, anywhere, anytime. If stablecoins have to get by in the clearings of the regulatory jungle, bitcoin floats breezily and limitlessly in the sky above.

Bitcoin was built on and for the internet, so it is natively programmable in ways that stablecoins can only vaguely approximate. And far from needing third-party custodians, bitcoin transfers are direct and disintermediated between the millions of users everywhere. The future stablecoins promise without much credibility is already the present for bitcoin.

It’s Easier to Win the Race without Hurdles

Utility is one of the central concepts in economics because it’s the mystic substance of decision making. People choose what they find most useful, and you know what’s most useful because it’s what people have chosen.

People are using stablecoins, which proves their utility. That usefulness isn’t going to go away, but regulation limits it. Stablecoins’ growth will stop where their utility is roughly matched by the friction that regulation induces. And the current state and probable future of regulation suggest that we’re getting pretty close to this equilibrium.

But since Bitcoin is not centralized and does not feed off state-based fiat currency, it is inherently harder to regulate and consequently attracts much less regulation. It’s also digitally native, which makes it a natural fit for a world of global commerce and value that flows frictionlessly across borders from one app anywhere to another. If regulation is what limits stablecoins’ utility and bitcoin is subject to much less regulation, it’s pretty clear who’s going to win the utility race. 

This is a guest post by Roy Sheinfeld from Breez. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.

This post Stablecoins: Evolution, not a Revolution first appeared on Bitcoin Magazine and is written by Roy Sheinfeld.

Digital Forensics: Analyzing BlackEnergy3 with Volatility

22 December 2025 at 12:19

Welcome back, aspiring digital forensic investigators.

The malware ecosystem is vast and constantly evolving. New samples appear every day, shared across underground forums and malware repositories. Some of these threats are short-lived, while others leave a lasting mark on history. Today, we are going to analyze one of those historically significant threats called BlackEnergy (for more on Blackenergy3 and it’s use to black out Ukraine, see the excellent article here by OTW). BlackEnergy is a malware family that gained global attention after being linked to large-scale cyber operations, most notably attacks against critical infrastructure. While it began as a relatively simple tool, it evolved into a sophisticated platform used in highly targeted campaigns. In this article, we will examine a memory dump from an infected Windows 7 system and use Volatility 3 to understand how BlackEnergy behaves in memory and how we can identify it during a forensic investigation.

Understanding BlackEnergy

BlackEnergy first appeared in the mid-2000s as a relatively basic DDoS bot. Early versions were used mainly to flood websites and disrupt online services. Over time, however, the malware evolved significantly. Later variants transformed BlackEnergy into a modular implant capable of espionage, sabotage, and long-term persistence. By the time it was linked to attacks against Ukrainian energy companies, BlackEnergy was an operational platform. It supported plugins for credential theft, system reconnaissance, file exfiltration, and lateral movement. One of its most destructive uses was as a delivery mechanism for KillDisk, a wiper component designed to overwrite critical system structures, erase logs, and make machines unusable. These capabilities strongly suggest the involvement of a well-resourced and organized threat actor, commonly associated in public reporting with the group known as Voodoo Bear.

Starting the Analysis

Our investigation begins with a raw memory capture from an infected Windows 7 machine. Memory analysis is especially valuable in cases like this because advanced malware often hides itself on disk but leaves traces while running.

Profile Information

Before diving into artifacts, it is always a good idea to understand the environment we are working with. The windows.info plugin gives us essential information such as the operating system version, architecture, kernel details, and system time. This context helps ensure that later findings make sense and that we interpret timestamps correctly.

bash$ > vol -f WINDOWS-ROOTKIT.raw windows.info

windows profile info

Process Listing

One of the first steps in memory analysis is reviewing the list of processes that were running when the memory was captured. This gives us a snapshot of system activity at that moment.

bash$ > vol -f WINDOWS-ROOTKIT.raw windows.pslist

listing processes with volatility

During this step, two processes immediately stand out: rootkit.exe and DumpIt.exe. DumpIt is commonly used to acquire memory, so its presence is expected. The appearance of rootkit.exe, however, is an indicator of malicious activity and deserves closer inspection.

To gain more context, we can look at which processes had already exited and which were still running. Processes that have ended will show an exit time, while active ones usually display “N/A.”

bash$ > vol -f WINDOWS-ROOTKIT.raw windows.pslist | grep -avi n/a

listing stopped processes with volatility

Among the terminated processes, we see rootkit.exe, cmd.exe, and others. This alone does not prove anything, but it makes us wonder how these processes were launched.

By correlating their process IDs, we can reconstruct the execution chain.

bash$ > vol -f WINDOWS-ROOTKIT.raw windows.pslist | grep -iE “1484|1960|276|964”

grepping pids with volatility

Although the output may look messy at first, it tells a clear story. explorer.exe launched several child processes, including cmd.exe, rootkit.exe, DumpIt.exe, and notepad.exe. This means the malicious activity was initiated through a user session, not a background service or boot-level process. Attackers often hide behind legitimate parent processes to blend in with normal system behavior, but in this case, the activity still leaves a clear forensic trail.

Code Injection Analysis

A common technique used by advanced malware is process injection. Instead of running entirely on its own, malware injects malicious code into legitimate processes to evade detection. DLL injection is especially popular because it allows attackers to run code inside trusted system binaries.

To look for signs of injection, we use the malfind plugin.

bash$ > vol -f WINDOWS-ROOTKIT.raw windows.malware.malfind

finding code injection with volatility

Several processes are flagged, but svchost.exe immediately draws attention due to the presence of an MZ header. The MZ signature normally appears at the beginning of Windows executable files. Finding it inside the memory of a running service process strongly suggests injected executable code.

To investigate further, we dump the suspicious memory region.

vol -f WINDOWS-ROOTKIT.raw windows.malware.malfind --dump --pid 880

dumping malware with volatility

VirusTotal and Malware Identification

After calculating the hash of the dumped payload, we can check it against VirusTotal. The results say the injected code belongs to BlackEnergy.

analyzing malware with virustotal

This confirms that the malware was running inside svchost.exe as an implant. Historically, BlackEnergy was used to maintain access, collect information, and deliver destructive payloads such as KillDisk. During the Ukrainian power grid attacks, this approach allowed attackers to disrupt operations while actively complicating forensic investigations.

blackenergy mitre info

MITRE ATT&CK classifications help further explain how BlackEnergy operated. The malware used obfuscation to hide its true functionality, masquerading to appear as legitimate software, system binary proxy execution to abuse trusted Windows components, and sandbox evasion to avoid automated analysis. It also performed registry queries and system discovery to understand the environment before sending data back to its command-and-control servers over HTTP, a technique that remains common even today.

Strings Analysis and Persistence

Running strings on the memory image shows additional clues.

bash$ > strings WINDOWS-ROOTKIT.raw

using strings to find persistence in blackenergy

One particularly important finding is a reference to a .sys driver file, indicating that the malware persisted as a kernel driver. Driver-based persistence is more advanced than simple registry keys or scheduled tasks. It allows malware to load early during system startup and operate with high privileges, making detection and removal significantly harder.

Loaded DLL Analysis

To understand how the malware hides itself, we examine loaded modules using ldrmodules.

bash$ > vol -f WINDOWS-ROOTKIT.raw windows.ldrmodules --pid 880

listing loaded dlls with volatility

The DLL msxml3r.dll does not appear as loaded, initialized, or mapped in memory according to the module lists. When all these indicators are false, it often means the malware is deliberately hiding the module from standard enumeration methods. This is a classic rootkit technique designed to evade detection.

DumpIt.exe Investigation

Finally, we examine DumpIt.exe. Dumping the process and checking its hash reveals that it is, in fact, a trojan.

bash$ > vol -f WINDOWS-ROOTKIT.raw windows.dump --pid 276

dumping another malware with volatility
virustotal info for the trojan
mitre info for the trojan

Its behavior shows a wide range of capabilities, including file manipulation, registry modification, privilege changes, service-based persistence, driver interaction, and embedded payload execution. In short, this malware component acted as a support tool, enabling persistence, system control, and interaction with low-level components.

Timeline Reconstruction

Putting all the pieces together, we can reconstruct the likely sequence of events. A user session initiated explorer.exe, which then launched command-line activity. Rootkit.exe was executed, injecting BlackEnergy into svchost.exe. The malware established persistence through a driver, hid its components using rootkit techniques, and maintained control over the system. DumpIt.exe, masquerading as a legitimate tool, further supported these activities.

Summary

In this investigation, we used Volatility to analyze a memory dump from a Windows 7 system infected with BlackEnergy. By examining running processes, code injection artifacts, loaded modules, strings, and malware behavior, we found a sophisticated implant designed for stealth and persistence. The whole case is a reminder that advanced malware often lives in memory, hides inside trusted processes, and actively works against forensic analysis.

Digital Forensics: Volatility – Analyzing a Malicious VPN

10 December 2025 at 09:38

Welcome back, my aspiring digital investigators!

Many of you enjoyed our earlier lessons on Volatility, so today we will continue that journey with another practical case. It is always great to see your curiosity growing stronger. This time we will walk through the memory analysis of a Windows machine that was infected with a stealer, which posed as a VPN app. The system communicated quietly with a Command and Control server operated by a hacker, and it managed to bypass the network intrusion detection system by sending its traffic through a SOCKS proxy. This trick allowed it to speak to a malicious server without raising alarms. You are about to learn exactly how we uncovered it.

What Is a NIDS ?

Before we jump into memory analysis, let’s briefly talk about NIDS, which stands for Network Intrusion Detection System. A NIDS watches the network traffic that flows through your environment and looks for patterns that match known attacks or suspicious behavior. If a user suddenly connects to a dangerous IP address or sends strange data, the NIDS can raise an alert. However, attackers often try to hide their communication. One common method is to use a SOCKS proxy, which allows the malware to make its malicious connection indirectly. Because the traffic appears to come from a trusted or unknown third party instead of the real attacker’s server, the NIDS may fail to flag it.

Memory Analysis

Now that we understand the background, we can begin our memory investigation.

Evidence

In this case we received a memory dump that was captured with FTK Imager. This is the only piece of evidence available to us, so everything we discover must come from this single snapshot of system memory.

showing evidence for the analysis

Volatility Setup

If you followed the first part of our Volatility guide, you already know how to install Volatility in its own Python 3 environment. Whenever you need it, simply activate it:

bash$ > source ~/venvs/vol3/bin/activate

activating volatility

Malfind

Volatility includes a helpful plugin called malfind. In Volatility 3, malfind examines memory regions inside processes and highlights areas that look suspicious. Attackers often inject malicious code into legitimate processes, and malfind is designed to catch these injected sections. Volatility has already announced that this module will be replaced in 2026 by a new version called windows.malware.malfind, but for now it still works the same way.

To begin looking for suspicious activity, we run:

bash$ > vol -f MemoryDump.mem windows.malware.malfind

volatility malfind scan

The output shows references to a VPN, and several processes stand out as malicious. One in particular catches our attention: oneetx.exe. To understand its role, we need to explore the related processes. We can do that with pslist:

bash$ > vol -f MemoryDump.mem windows.pslist | grep -E "5896|7540|5704"

volatility widows pslist listing processes

We see that oneetx.exe launched rundll32.exe. This is a classic behavior in malware. Rundll32.exe is a legitimate Windows utility that loads and executes DLL files. Hackers love using it because it allows their malicious code to blend in with normal system behavior. If the malware hides inside a DLL, rundll32.exe can be used to run it without attracting much attention.

We have confirmed the malicious process, so now we will extract it from memory.

Analyzing the Malware

To analyze the malware more deeply, we need the actual executable. We use dumpfile and provide the process ID:

bash$ > vol -f MemoryDump.mem windows.dumpfile --pid 5896

dumping the malware from the memory

Volatility will extract all files tied to the process. To quickly locate the executable, we search for files ending in .exe:

bash$ > ls *exe*

Once we find the file, we calculate its hash so that we can look it up on VirusTotal:

bash$ > md5sum file.0x….oneetx.exe.img

hashing the malware
malware analysis on virus total

The malware is small, only 865 KB. This tells us it is a lightweight implant with limited features. A full-featured, multi-purpose implant such as a Sliver payload is usually much larger, sometimes around sixteen megabytes. Our sample steals information and sends it back to the hacker.

Viewing its behavior reveals several MITRE ATT&CK techniques, and from that we understand it is a stealer focused on capturing user input and collecting stolen browser cookies.

mitre malware info

Next, we want to know which user launched this malware. We can use filescan for that:

bash$ > vol -f MemoryDump.mem windows.filescan | grep "oneetx.exe"

volatility filescan

It turns out the user was Tammam, who accidentally downloaded and executed the malware.

Memory Protection

Before we continue, it is worth discussing memory protection. Operating systems apply different permissions to memory regions, such as read, write, or execute. Malware often marks its injected code regions as PAGE_EXECUTE_READWRITE, meaning the memory is readable, writable, and executable at the same time. This combination is suspicious because normal applications usually do not need this level of freedom. In our malfind results, we saw that the malicious code was stored in memory regions with these unsafe permissions.

volatility memory protection

Process Tree

Next, we review the complete process tree to understand what else was happening when the malware ran:

bash$ > vol -f MemoryDump.mem windows.pstree

volatility process tree

Two processes draw our attention: Outline.exe and tun2socks.exe. From their PIDs and PPIDs, we see that Outline.exe is the parent process.

Tun2socks.exe is commonly used to forward traffic from a VPN or proxy through a SOCKS interface. In normal security tools it is used to route traffic securely. However, attackers sometimes take advantage of it because it allows them to hide communication inside what looks like normal proxy traffic.

To understand how Outline.exe started, we trace its PID and PPID back to the original parent. In this case, explorer.exe launched multiple applications, including this one.

volatility psscan

Normally we would extract these executables and check their hashes as well, but since we have already demonstrated this process earlier, we can skip repeating it here.

Network Connections

Malware usually communicates with a Command and Control server so the hacker can control the infected system, steal data, or run remote commands. Some malware families, such as ransomware, do not rely heavily on network communication, but stealers typically do.

We check the network connections from our suspicious processes:

bash$ > vol -f MemoryDump.mem windows.netscan | grep -iE "outline|tun2socks|oneetx"

volatility netscan

Tun2socks connected to 38.121.43.65, while oneetx.exe communicated with 77.91.124.20. After checking their reputations, we see that one of the IPs is malicious and the other is clean. This strongly suggests that the attacker used a proxy chain to hide their real C2 address behind an innocent-looking server.

virus total malicious ip
virus total clean ip

The malicious IP is listed on tracker.viriback.com, which identifies the malware family as Amadey. Amadey is known for stealing data and providing remote access to infected machines. It usually spreads through phishing and fake downloads, and it often hides behind ordinary-looking websites to avoid suspicion.

c2 tracker ip info

The tracker even captured an HTTP login page for the C2 panel. The interface is entirely in Russian, so it is reasonable to assume a Russian-speaking origin.

ip info
c2 login page

Strings Analysis

Now that we understand the basic nature of the infection, we search for strings in the memory dump that mention the word “stealer”:

bash$ > strings MemoryDump.mem | grep -ai stealer

keyword search in malware with strings

We find references to RedLine Stealer, a well-known and widely sold malware. RedLine is commonly bought on underground markets. It comes either as a one-time purchase or as a monthly subscription. This malware collects browser passwords, auto-fill data, credit card information, and sometimes even cryptocurrency wallets. It also takes an inventory of the system, gathering information about hardware, software, security tools, and user details. More advanced versions can upload or download files, run commands, and report regularly to the attacker.

We can also use strings to search for URLs where the malware may have uploaded stolen data.

finding urls in malware with strings

Several directories appear, and these could be the locations where the stolen credentials were being stored.

Timeline

Tammam wanted to download a VPN tool and came across what looked like an installer. When he launched it, the application behaved strangely, but by then the infection had already begun. The malware injected malicious code, and used rundll32.exe to run parts of its payload. Tun2socks.exe and Outline.exe helped the malware hide its communication by routing traffic through a SOCKS proxy, which allowed it to connect safely to the attacker’s C2 server at 77.91.124.20. From there, the stealer collected browser data, captured user inputs, and prepared to upload stolen credentials to remote directories. The entire activity was visible inside the memory dump we analyzed.

Summary

Stealers are small but very dangerous pieces of malware designed to quietly collect passwords, cookies, autofill data, and other personal information. Instead of causing loud damage, they focus on moving fast and staying hidden. Many rely on trusted Windows processes or proxy tools to disguise their activity, and they often store most of their traces only in memory, which is why memory forensics is so important when investigating them. Most popular stealers, like RedLine or Amadey, are sold on underground markets as ready-made kits, complete with simple dashboards and subscription models. Their goal is always the same.

Digital Forensics: Volatility – Memory Analysis Guide, Part 2

1 December 2025 at 10:31

Hello, aspiring digital forensics investigators!

Welcome back to our guide on memory analysis!

In the first part, we covered the fundamentals, including processes, dumps, DLLs, handles, and services, using Volatility as our primary tool. We created this series to give you more clarity and help you build confidence in handling memory analysis cases. Digital forensics is a fascinating area of cybersecurity and earning a certification in it can open many doors for you. Once you grasp the key concepts, you’ll find it easier to navigate the field. Ultimately, it all comes down to mastering a core set of commands, along with persistence and curiosity. Governments, companies, law enforcement and federal agencies are all in need of skilled professionals  As cyberattacks become more frequent and sophisticated, often with the help of AI, opportunities for digital forensics analysts will only continue to grow.

Now, in part two, we’re building on that to explore more areas that help uncover hidden threats. We’ll look at network info to see connections, registry keys for system changes, files in memory, and some scans like malfind and Yara rules to find malware. Plus, as promised, there are bonuses at the end for quick ways to pull out extra details

Network Information

As a beginner analyst, you’d run network commands to check for sneaky connections, like if malware is phoning home to hackers. For example, imagine investigating a company’s network after a data breach, these tools could reveal a hidden link to a foreign server stealing customer info, helping you trace the attacker.

Netscan‘ scans for all network artifacts, including TCP/UDP. ‘Netstat‘ lists active connections and sockets. In Vol 2, XP/2003-specific ones like ‘connscan‘ and ‘connections‘ focus on TCP, ‘sockscan‘ and ‘sockets‘ on sockets, but they’re old and not present in Vol 3.

Volatility 2:

vol.py -f “/path/to/file” ‑‑profile <profile> netscan

vol.py -f “/path/to/file” ‑‑profile <profile> netstat

XP/2003 SPECIFIC:

vol.py -f “/path/to/file” ‑‑profile <profile> connscan

vol.py -f “/path/to/file” ‑‑profile <profile> connections

vol.py -f “/path/to/file” ‑‑profile <profile> sockscan

vol.py -f “/path/to/file” ‑‑profile <profile> sockets

Volatility 3:

vol.py -f “/path/to/file” windows.netscan

vol.py -f “/path/to/file” windows.netstat

bash$ > vol -f Windows7.vmem windows.netscan

netscan in volatility

This output shows network connections with protocols, addresses, and PIDs. Perfect for spotting unusual traffic.

bash$ > vol -f Windows7.vmem windows.netstat

netstat in volatility

Here, you’ll get a list of active sockets and states, like listening or established links.

Note, the XP/2003 specific plugins are deprecated and therefore not available in Volatility 3, although are still common in the poorly financed government sector.

Registry

Hive List

You’d use hive list commands to find registry hives in memory, which store system settings malware often tweaks these for persistence. Say you’re checking a home computer after suspicious pop-ups. This could show changes to startup keys that launch bad software every boot.

hivescan‘ scans for hive structures. ‘hivelist‘ lists them with virtual and physical addresses.

Volatility 2:

vol.py -f “/path/to/file” ‑‑profile <profile> hivescan

vol.py -f “/path/to/file” ‑‑profile <profile> hivelist

Volatility 3:

vol.py -f “/path/to/file” windows.registry.hivescan

vol.py -f “/path/to/file” windows.registry.hivelist

bash$ > vol -f Windows7.vmem windows.registry.hivelist

hivelist in volatility

This lists the registry hives with their paths and offsets for further digging.

bash$ > vol -f Windows7.vmem windows.registry.hivescan

hivescan in volatility

The scan output highlights hive locations in memory.

Printkey

Printkey is handy for viewing specific registry keys and values, like checking for malware-added entries. For instance, in a ransomware case, you might look at keys that control file associations to see if they’ve been hijacked.

Without a key, it shows defaults, while -K or –key targets a certain path.

Volatility 2:

vol.py -f “/path/to/file” ‑‑profile <profile> printkey

vol.py -f “/path/to/file” ‑‑profile <profile> printkey -K “Software\Microsoft\Windows\CurrentVersion”

Volatility 3:

vol.py -f “/path/to/file” windows.registry.printkey

vol.py -f “/path/to/file” windows.registry.printkey ‑‑key “Software\Microsoft\Windows\CurrentVersion”

bash$ > vol -f Windows7.vmem windows.registry.printkey

windows registry print key in volatility

This gives a broad view of registry keys.

bash$ > vol -f Windows7.vmem windows.registry.printkey –key “Software\Microsoft\Windows\CurrentVersion”

widows registry printkey in volatility

Here, it focuses on the specified key, showing subkeys and values.

Files

File Scan

Filescan helps list files cached in memory, even deleted ones, great for finding malware files that were run but erased from disk. This can uncover temporary files from the infection.

Both versions scan for file objects in memory pools.

Volatility 2:

vol.py -f “/path/to/file” ‑‑profile <profile> filescan

Volatility 3:

vol.py -f “/path/to/file” windows.filescan

bash$ > vol -f Windows7.vmem windows.filescan

scanning files in volatility

This output lists file paths, offsets, and access types.

File Dump

You’d dump files to extract them from memory for closer checks, like pulling a suspicious script. In a corporate espionage probe, dumping a hidden document could reveal leaked secrets.

Without options, it dumps all. With offsets or PID, it targets specific ones. Vol 3 uses virtual or physical addresses.

Volatility 2:

vol.py -f “/path/to/file” ‑‑profile <profile> dumpfiles ‑‑dump-dir=“/path/to/dir”

vol.py -f “/path/to/file” ‑‑profile <profile> dumpfiles ‑‑dump-dir=“/path/to/dir” -Q <offset>

vol.py -f “/path/to/file” ‑‑profile <profile> dumpfiles ‑‑dump-dir=“/path/to/dir” -p <PID>

Volatility 3:

vol.py -f “/path/to/file” -o “/path/to/dir” windows.dumpfiles

vol.py -f “/path/to/file” -o “/path/to/dir” windows.dumpfiles ‑‑virtaddr <offset>

vol.py -f “/path/to/file” -o “/path/to/dir” windows.dumpfiles ‑‑physaddr <offset>

bash$ > vol -f Windows7.vmem windows.dumpfiles

duping files in volatility

This pulls all cached files Windows has in RAM.

Miscellaneous

Malfind

Malfind scans for injected code in processes, flagging potential malware.

Vol 2 shows basics like hexdump. Vol 3 adds more details like protection and disassembly.

Volatility 2:

vol.py -f “/path/to/file” ‑‑profile <profile> malfind

Volatility 3:

vol.py -f “/path/to/file” windows.malfind

bash$ > vol -f Windows7.vmem windows.malfind

scanning for suspcious injections with malfind in in volatility

This highlights suspicious memory regions with details.

Yara Scan

Yara scan uses rules to hunt for malware patterns across memory. It’s like a custom detector. For example, during a widespread attack like WannaCry, a Yara rule could quickly find infected processes.

Vol 2 uses file path. Vol 3 allows inline rules, file, or kernel-wide scan.

Volatility 2:

vol.py -f “/path/to/file” yarascan -y “/path/to/file.yar”

Volatility 3:

vol.py -f “/path/to/file” windows.vadyarascan ‑‑yara-rules <string>

vol.py -f “/path/to/file” windows.vadyarascan ‑‑yara-file “/path/to/file.yar”

vol.py -f “/path/to/file” yarascan.yarascan ‑‑yara-file “/path/to/file.yar”

bash$ > vol -f Windows7.vmem windows.vadyarascan –yara-file yara_fules/Wannacrypt.yar

scanning with yara rules in volatility

As you can see we found the malware and all related processes to it with the help of the rule

Bonus

Using the strings command, you can quickly uncover additional useful details, such as IP addresses, email addresses, and remnants from PowerShell or command prompt activities.

Emails

bash$ > strings Windows7.vmem | grep -oE "\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}\b"

viewing emails in a memory capture

IPs

bash$ > strings Windows7.vmem | grep -oE "\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}\b"

viewing ips in a memory capture

Powershell and CMD artifacts

bash$ > strings Windows7.vmem | grep -E "(cmd|powershell|bash)[^\s]+"

viewing powershell commands in a memory capture

Summary

By now you should feel comfortable with all the network analysis, file dumps, hives and registries we had to go through. As you practice, your confidence will grow fast. The commands covered here will help you solve most of the cases as they are fundamental. Also, don’t forget that Volatility has a lot more different plugins that you may want to explore. Feel free to come back to this guide anytime you want. Part 1 will remind you how to approach a memory dump, while Part 2 has the commands you need. In this part, we’ve expanded your Volatility toolkit with network scans to track connections, registry tools to check settings, file commands to extract cached items, and miscellaneous scans like malfind for injections and Yara for pattern matching. Together they give you a solid set of steps. 

If you want to turn this into a career, our digital forensics courses are built to get you there. Many students use this training to prepare for industry certifications and job interviews. Our focus is on the practical skills that hiring teams look for.

Digital Forensics: Volatility – Memory Analysis Guide, Part 1

3 November 2025 at 11:20

Welcome back, aspiring DFIR investigators!

If you’re diving into digital forensics, memory analysis is one of the most exciting and useful skills you can pick up. Essentially, you take a snapshot of what’s happening inside a computer’s brain right at that moment and analyze it. Unlike checking files on a hard drive, which shows what was saved before, memory tells you about live actions. Things like running programs or hidden threats that might disappear when the machine shuts down. This makes it super helpful for solving cyber incidents, especially when bad guys try to cover their tracks.

In this guide, we’re starting with the basics of memory analysis using a tool called Volatility. We’ll cover why it’s so important, how to get started, and some key commands to make you feel confident. This is part one, where we focus on the foundations and give instructions. Stick around for part two, where we’ll keep exploring Volatility and dive into network details, registry keys, files, and scans like malfind and Yara rules. Plus, if you make it through part two, there are some bonuses waiting to help you extract even more insights quickly.

Memory Forensics

Memory analysis captures stuff that disk forensics might miss. For example, after a cyber attack, malware could delete its own files or run without saving anything to the disk at all. That leaves you with nothing to find on the hard drive. But in memory, you can spot remnants like active connections or secret codes. Even law enforcement grabs memory dumps from suspects’ computers before powering them off. Once it’s off, the RAM clears out, and booting back up might be tricky if the hacker sets traps. Hackers often use tricks like USB drives that trigger wipes of sensitive data on shutdown, cleaning everything in seconds so authorities find nothing. We’re not diving into those tricks here, but they show why memory comes first in many investigations.

Lucky for us, Volatility makes working with these memory captures straightforward. It started evolving, and in 2019, Volatility 3 arrived with better syntax and easier to remember commands. We’ll look at both Volatility 2 and 3, sharing commands to get you comfortable. These should cover what most analysts need.

Memory Gems

Below is some valuable data you can find in RAM for investigations:

1. Network connections

2. File handles and open files

3. Open registry keys

4. Running processes on the system

5. Loaded modules

6. Loaded device drivers

7. Command history and console sessions

8. Kernel data structures

9. User and credential information

10. Malware artifacts

11. System configuration

12. Process memory regions

Keep in mind, sometimes key data like encryption keys hides in memory. Memory forensics can pull this out, which might be a game-changer for a case.

Approach to Memory Forensics

In this section we will describe a structured method for conducting memory forensics, designed to support investigations of data in memory. It is based on the six-step process from SANS for analyzing memory.

Identifying and Checking Processes

Start by listing all processes that are currently running. Harmful programs can pretend to be normal ones, often using names that are very similar to trick people. To handle this:

1. List every active process.

2. Find out where each one comes from in the operating system.

3. Compare them to lists of known safe processes.

4. Note any differences or odd names that stand out.

Examining Process Details

After spotting processes that might be problematic, look closely at the related dynamic link libraries (DLLs) and resources they use. Bad software can hide by misusing DLLs. Key steps include:

1. Review the DLLs connected to the questionable process.

2. Look for any that are not approved or seem harmful.

3. Check for evidence of DLLs being inserted or taken over improperly.

Reviewing Network Connections

A lot of malware needs to connect to the internet, such as to contact control servers or send out stolen information. To find these activities:

1. Check the open and closed network links stored in memory.

2. Record any outside IP addresses and related web domains.

3. Figure out what the connection is for and why it’s happening.

4. Confirm if the process is genuine.

5. See if it usually needs network access.

6. Track it back to the process that started it.

7. Judge if its actions make sense.

Finding Code Injection

Skilled attackers may use methods like replacing a process’s code or working in hidden memory areas. To detect this:

1. Apply tools for memory analysis to spot unusual patterns or signs of these tactics.

2. Point out processes that use strange memory locations or act in unexpected ways.

Detecting Rootkits

Attackers often aim for long-term access and hiding. Rootkits bury themselves deep in the system, giving high-level control while staying out of sight. To address them:

1. Search for indicators of rootkit presence or major changes to the OS.

2. Spot any processes or drivers with extra privileges or hidden traits.

Isolating Suspicious Items

Once suspicious processes, drivers, or files are identified, pull them out for further study. This means:

1. Extract the questionable parts from memory.

2. Save them safely for detailed review with forensic software.

The Volatility Framework

A widely recommended option for memory forensics is Volatility. This is a prominent open-source framework used in the field. Its main component is a Python script called Volatility, which relies on various plugins to carefully analyze memory dumps. Since it is built on Python, it can run on any system that supports Python.

Volatility’s modules, also known as plugins, are additional features that expand the framework’s capabilities. They help pull out particular details or carry out targeted examinations on memory files.

Frequently Used Volatility Modules

Here are some modules that are often used:

pslist: Shows the active processes.

cmdline: Reveals the command-line parameters for processes.

netscan: Checks for network links and available ports.

malfind: Looks for possible harmful code added to processes.

handles: Examines open resources.

svcscan: Displays services in Windows.

dlllist: Lists the dynamic-link libraries loaded in a process.

hivelist: Identifies registry hives stored in memory.

You can find documentation on Volatility here:

Volatility v2: https://github.com/volatilityfoundation/volatility/wiki/Command-Reference

Volatility v3: https://volatility3.readthedocs.io/en/latest/index.html

Installation

Installing Volatility 3 is quite easy and will require a separate virtual environment to keep things organized. Create it first before proceeding with the rest:

bash$ > python3 -m venv ~/venvs/vol3

bash$ > source ~/venvs/vol3

Now you are ready to install it:

bash$ > pip install volatility3

installing volatility

Since we are going to cover Yara rules in Part 2, we will need to install some dependencies:

bash$ > sudo apt install -y build-essential pkg-config libtool automake libpcre3-dev libjansson-dev libssl-dev libyara-dev python3-dev

bash$ > pip install yara-python pycryptodome

installing yara for volatility

Yara rules are important and they help you automate half the analysis. There are hundreds of these rules available on Github, so you can download and use them each time you analyze the dump. While these rules can find a lot of things, there is always a chance that malware can fly under the radar, as attackers change tactics and rewrite payloads. 

Now we are ready to work with Volatility 3.

Plugins

Volatility comes with multiple plugins. To list all the available plugins do this:

bash$ > vol -h

showing available plugins in volatility

Each of these plugins has a separate help menu with a description of what it does.

Memory Analysis Cheat Sheet

Image Information

Imagine you’re an analyst investigating a hacked computer. You start with image information because it tells you basics like the OS version and architecture. This helps Volatility pick the right settings to read the memory dump correctly. Without it, your analysis could go wrong. For example, if a company got hit by ransomware, knowing the exact Windows version from the dump lets you spot if the malware targeted a specific weakness.

In Volatility 2, ‘imageinfo‘ scans for profiles, and ‘kdbgscan‘ digs deeper for kernel debug info if needed. Volatility 3’s ‘windows.info‘ combines this, showing 32/64-bit, OS versions, and kernel details all in one and it’s quicker.

bash$ > vol -f Windows.vmem windows.info

getting image info with volatility

Here’s what the output looks like, showing key system details to guide your next steps.

Process Information

As a beginner analyst, you’d run process commands to list what’s running on the system, like spotting a fake “explorer.exe” that might be malware stealing data. Say you’re checking a bank employee’s machine after a phishing attack, these commands can tell you if suspicious programs are active, and help you trace the breach.

pslist‘ shows active processes via kernel structures. ‘psscan‘ scans memory for hidden ones (good for rootkits). ‘pstree‘ displays parent-child relationships like a family tree. ‘psxview‘ in Vol 2 compares lists to find hidden processes.

Note that Volatility 2 wants you to specify the profile. You can find out the profile while gathering the image info.

Volatility 2:

vol.py -f “/path/to/file” ‑‑profile <profile> pslist

vol.py -f “/path/to/file” ‑‑profile <profile> psscan

vol.py -f “/path/to/file” ‑‑profile <profile> pstree

vol.py -f “/path/to/file” ‑‑profile <profile> psxview

Volatility 3:

vol.py -f “/path/to/file” windows.pslist

vol.py -f “/path/to/file” windows.psscan

vol.py -f “/path/to/file” windows.pstree

Now let’s see what we get:

bash$ > vol -f Windows7.vmem windows.pslist

displaying a process list with volatility

This output lists processes with PIDs, names, and start times. Great for spotting outliers.

bash$ > vol -f Windows.vmem windows.psscan

running a process scan with volatility to find hidden processes

Here, you’ll see a broader scan that might catch processes trying to hide.

bash$ > vol -f Windows7.vmem windows.pstree

listing process trees with volatility

This tree view helps trace how processes relate, like if a browser spawned something shady.

Displaying the entire process tree will look messy, so we recommend a more targeted approach with –pid

Process Dump

You’d use process dump when you spot a suspicious process and want to extract its executable for closer inspection, like with antivirus tools. For instance, if you’re analyzing a system after a data leak, dumping a weird process could reveal it is spyware sending info to hackers.

Vol 2’s ‘procdump‘ pulls the exe for a PID. Vol 3’s ‘dumpfiles‘ grabs the exe plus related DLLs, giving more context.

Volatility 2:

vol.py -f “/path/to/file” ‑‑profile <profile> procdump -p <PID> ‑‑dump-dir=“/path/to/dir”

Volatility 3:

vol.py -f “/path/to/file” -o “/path/to/dir” windows.dumpfiles ‑‑pid <PID>

We already have a process we are interested in:

bash$ > vol -f Windows.vmem windows.dumpfiles --pid 504

dumping files with volatility

After the dump, check the output and analyze it further.

Memdump

Memdump is key for pulling the full memory of a process, which might hold passwords or code snippets. Imagine investigating insider theft, dumping memory from an email app could show unsent drafts with stolen data.

Vol 2’s ‘memdump extracts raw memory for a PID. Vol 3’s ‘memmap with –dump maps and dumps regions, useful for detailed forensics.

Volatility 2:

vol.py -f “/path/to/file” ‑‑profile <profile> memdump -p <PID> ‑‑dump-dir=“/path/to/dir”

Volatility 3:

vol.py -f “/path/to/file” -o “/path/to/dir” windows.memmap ‑‑dump ‑‑pid <PID>

Let’s see the output for our process:

bash$ > vol -f Windows7.vmem windows.memmap --dump --pid 504

pulling memory of processes with volatility

This shows the memory map and dumps files for deep dives.

DLLs

Listing DLLs helps spot injected code, like malware hiding in legit processes. Unusual DLLs might point to infection.

Both versions list loaded DLLs for a PID, but Vol 3 is profile-free and faster.

Volatility 2:

vol.py -f “/path/to/file” ‑‑profile <profile> dlllist -p <PID>

Volatility 3:

vol.py -f “/path/to/file” windows.dlllist ‑‑pid <PID>

Let’s see the DLLs loaded in our memory dump:

bash$ > vol -f Windows7.vmem windows.dlllist --pid 504

listing loaded DLLs in volatility

Here you see all loaded DLLs of this process. You already know how to dump processes with their DLLs for a more thorough analysis. 

Handles

Handles show what a process is accessing, like files or keys crucial for seeing if malware is tampering with system parts. In a ransomware case, handles might reveal encrypted files being held open or encryption keys used to encrypt data.

Both commands list handles for a PID. Similar outputs, but Vol 3 is streamlined.

Volatility 2:

vol.py -f “/path/to/file” ‑‑profile <profile> handles -p <PID>

Volatility 3:

vol.py -f “/path/to/file” windows.handles ‑‑pid <PID>

Let’s see the handles our process used:

bash$ > vol -f Windows.vmem windows.handles --pid 504

listing handles in volatility

It gave us details, types and names for clues.

Services

Services scan lists background programs, helping find persistent malware disguised as services. If you’re probing a server breach, this could uncover a backdoor service.

Use | more to page through long lists. Outputs are similar, showing service names and states.

Volatility 2:

vol -f “/path/to/file” ‑‑profile <profile> svcscan | more

Volatility 3:

vol -f “/path/to/file”  windows.svcscan | more

Since this technique is often abused, a lot can be discovered here:

bash$ > vol -f Windows7.vmem windows.svcscan

listing windows services in volatility

Give it a closer look and spend enough time here. It’s good to familiarize yourself with native services and their locations

Summary

We’ve covered the essentials of memory analysis with Volatility, from why it’s vital to key commands for processes, dumps, DLLs, handles, and services. Apart from the commands, now you know how to approach memory forensics and what actions you should take. As we progress, more articles will be coming where we practice with different cases. We already have a memory dump of a machine that suffered a ransomware attack, which we analyzed with you recently. In part two, you will build on this knowledge by exploring network info, registry, files, and advanced scans like malfind and Yara rules. And for those who finish part two, some handy bonuses await to speed up your work even more. Stay tuned!

The post Digital Forensics: Volatility – Memory Analysis Guide, Part 1 first appeared on Hackers Arise.

❌
❌