> ## Content Index > Fetch the complete content index at: https://f4n6.co.uk/llms.txt > Use this file to discover other available public pages before exploring further. # Guide to deploying local Ghidra Server for malware lab data persistence - URL: https://f4n6.co.uk/security-feed/guide-to-deploying-local-ghidra-server-for-malware-lab-data-persistence/ - Published: 2026-10-29T10:51:28.000Z - Updated: 2026-10-29T10:51:28.000Z - Author: Jeff Davies - Tags: #security-feed ## 1\. Executive summary This item is a SANS Internet Storm Center diary by Xavier Mertens describing how to deploy a local Ghidra Server to persist reverse-engineering work outside an analysis VM that may be reverted to a clean snapshot. It is a defensive lab-architecture guide, not a report of an intrusion, vulnerability or campaign. No CVE has been assigned and no actor is named. The relevance to EMEA financial services is indirect: any in-house malware analysis or incident-response function that uses Ghidra and snapshot-based VMs risks losing annotated work, and the diary's own warning is that a Ghidra Server repository holds the raw bytes of every imported sample, so it must be treated as malware-hosting infrastructure and never exposed to the internet. The bottom-line risk is misconfiguration of a Java RMI service that stores live malware, not exploitation of a known flaw. ## 2\. Regulatory framing No specific DORA/NIS2 article is directly engaged by this item. ## 3\. Technical analysis & attack chain There is no attack chain. The item describes a defensive deployment. What follows is the deployment mechanism and the security-relevant properties an analyst needs to reproduce or assess it. Ghidra stores analysis work in a project, which on disk is a `.gpr` file plus a `.rep` directory. Renamed functions, comments, structures and bookmarks live there. Reverting an analysis VM to a snapshot discards those changes, which is the problem the server solves. Ghidra Server ships in the standard distribution with no extra download or licence and turns local projects into shared projects backed by a central repository. The diary lists the benefits as persistence across VM reverts, versioning (each check-in creates a new program version with a comment, comparable to a git repository), use from multiple clients, per-repository collaboration permissions, and confidentiality because samples stay in the lab rather than going to a third-party service. The reference deployment is Ghidra 12.1.4 in an Ubuntu container on a Proxmox host. Recommended specifications are a small Linux VM or container kept separate from analysis VMs, 2 CPUs, 4GB RAM, 8GB storage (dependent on sample volume) and JDK 21 or newer. Server and client Ghidra versions must match to avoid incompatibility. Setup steps as given: 1. Install a JRE and unzip: `apt install openjdk-25-jre-headless unzip`. 2. Create a dedicated no-login account: `useradd -r -m -d /opt/ghidra -s /usr/sbin/nologin ghidra`. 3. Unpack under `/opt`, symlink `ghidra-current` to `ghidra_12.1.4_PUBLIC`, and create `/opt/ghidra-repos` owned by `ghidra`. 4. Edit `server/server.conf`: set `ghidra.repositories.dir=/opt/ghidra-repos`, set the JVM account, and pass server parameters. The diary's parameters are `-a0` (server-managed passwords), `-e90` (90-day password expiry), `-ip ghidra.lab.local` (hostname announced to clients), and the repositories directory as the final parameter. 5. Install and start the service with `/opt/ghidra-current/server/svrInstall`, then check `systemctl status ghidraSvr` and confirm listeners with `ss -tlnp | grep -E '1310[0-2]'`. 6. Create users with `./svrAdmin -add ` and list them with `./svrAdmin -list -users`. New users receive the initial password `changeme` and must change it at first login. `svrAdmin` commands are queued and processed by the running server within seconds. 7. Create repositories from the Ghidra client. Grant access from the client (Project > Edit Access List) or server-side with `./svrAdmin -grant john +w MalwareLab`, where `+r` is read-only, `+w` read/write and `+a` admin. Authentication modes named are `-a0` (local Ghidra passwords), `-a2` (PKI with client certificates) and `-a4` (JAAS, for LDAP or Active Directory integration). Anonymous access should stay disabled. The `-ip` parameter matters because RMI returns that name to clients, which then reconnect on ports 13101 and 13102; if clients cannot resolve it they reach the server on the first port and then fail. To bind to a single interface, add `-i
`. A shared project still creates a local `.gpr` and `.rep` containing connection settings, a cache and checked-out copies. Importing a binary does not send it to the server; it stays private until the analyst right-clicks and selects "Add to Version Control...". To recover after a VM revert, create a new Shared Project, connect to the server and select the existing repository rather than creating a new one; the project tree repopulates with all checked-in programs. A file still checked out by the old VM instance can be released via right-click, View Checkouts, terminate the stale entry. Security-relevant properties. Ghidra Server is a Java RMI service. The diary states the repositories contain the raw bytes of every imported sample and instructs that the server be treated as hosting live malware, kept in the malware analysis lab network, and never exposed to the internet. Nothing in the repository is executed by the server. The diary also points to the community ghidra-server.org service and warns that, like any cloud service, using it means sharing your data. Discrepancy to note. The diary's networking remarks list TCP/13100 and TCP/13101 as the ports clients must reach, while its own `-ip` explanation and the `ss` check reference 13101 and 13102\. The port set is inconsistent within the source; confirm the actual listeners on your build with `ss` before writing firewall rules. Single-sourced. All of the above is from one SANS ISC diary and was not corroborated against Ghidra's own documentation in the material provided. Verify configuration keys and port behaviour against the Ghidra Server documentation for your version before production use. ## 4\. Mitigation & containment This item is a deployment guide, so the actions are hardening steps for a lab service that stores live malware. ### P1 within 24h - If a Ghidra Server is already running, confirm it is not reachable from the internet or from corporate user networks. Check listeners with `ss -tlnp | grep -E '1310[0-2]'` and confirm firewall rules restrict 13100-13102 to the analysis lab segment only. - Bind the service to the lab or VPN interface with `-i
` in `server/server.conf` rather than all interfaces. - Change any account still on the default `changeme` password and confirm `-e90` expiry is active. ### P2 within 72h - Keep server and client on the same Ghidra version (12.1.4 in the reference build) to avoid incompatibility. - Choose an authentication mode that fits your estate: `-a0` for standalone lab passwords, `-a2` for client certificates, `-a4` for JAAS against LDAP or Active Directory. Leave anonymous access disabled. - Ensure clients can resolve the hostname announced by `-ip`; a resolution failure shows as a connection that succeeds on the first port then fails. - Grant repository permissions least-privilege with `svrAdmin -grant +r|+w|+a ` and review the access list periodically. ### P3 within 7 days - Treat the repository host as malware-handling infrastructure: separate VM or container from analysis VMs, no shared credentials with corporate systems, and backup of `/opt/ghidra-repos` handled under the same controls as malware samples. - If using the community ghidra-server.org service instead of a local server, assess it as a third-party data-sharing arrangement before importing any client or incident-response sample. - Document the recovery procedure (new Shared Project, connect to existing repository, release stale checkouts via View Checkouts) so analysts do not recreate a repository and lose history after a VM revert. ## 5\. Indicators of compromise No indicators of compromise available in the source material. ## 6\. Detection Insufficient indicators to author detection rules. ## 7\. Sources - Xavier Mertens, SANS Internet Storm Center, "Deploying a Local Ghidra Server for Your Malware Analysis Lab", 2026-10-29\. https://isc.sans.edu/diary/rss/33470 - NSA, Ghidra (referenced in the diary). https://github.com/nationalsecurityagency/ghidra - ghidra-server.org community server (referenced in the diary). https://ghidra-server.org ## 8\. Adverse Trace position This is a defensive lab-architecture diary with no vulnerability, actor or campaign attached, so there is no severity to assign and no CISA KEV or EPSS position to take. The client impact is limited to organisations running in-house Ghidra-based malware analysis: the exposure is a Java RMI service holding raw malware samples, and the diary's own guidance is that it stays inside the lab network and off the internet. The port inconsistency between 13100/13101 and 13101/13102 is unresolved in the source and should be checked on the build in use. Adverse Trace will not issue detection content for this item, will treat the deployment guidance as single-sourced until Ghidra's own documentation is checked, and will revisit if a Ghidra Server exposure or a flaw in the RMI service is reported. Clients who want the lab persistence model reviewed against their segmentation can request a scoping call. --- [Read the original source →](https://isc.sans.edu/diary/rss/33470?ref=f4n6.co.uk) *Published via PulseTrace — Adverse Trace threat intelligence.*