{
	"id": "3bb7c878-4efe-49b7-9f7d-01d4e05bf886",
	"created_at": "2026-04-06T01:32:01.128688Z",
	"updated_at": "2026-04-10T13:11:25.26857Z",
	"deleted_at": null,
	"sha1_hash": "a00e0f1c92675875e7563d3b847e91cd96dd7306",
	"title": "Set up your own malware analysis lab with VirtualBox, INetSim and Burp",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 739642,
	"plain_text": "Set up your own malware analysis lab with VirtualBox, INetSim\r\nand Burp\r\nBy christophetd\r\nPublished: 2017-06-05 · Archived: 2026-04-06 00:34:27 UTC\r\nIn this post we will set up a virtual lab for malware analysis. We’ll create an isolated virtual network separated\r\nfrom the host OS and from the Internet, in which we’ll setup two victim virtual machines (Ubuntu and Windows\r\n7) as well as an analysis server to mimic common Internet services like HTTP or DNS. Then, we’ll be able to log\r\nand analyze the network communications of any Linux or Windows malware, which will unknowingly connect\r\nto our server instead of the Internet. We demonstrate the setup with a real life use case where we analyze the\r\ntraffic of the infamous TeslaCrypt ransomware, a now defunct ransomware which infected a large number of\r\nsystems from 2015 to mid-2016.\r\nThis guide includes quite a lot of material, so here’s a table of contents to give you an overview of what we’ll\r\ncover and let you jump directly to a section if you’d like.\r\n1. Creating the virtual machines\r\nHere are two links you can use to download Ubuntu and Windows 7 virtual machine images.\r\nUbuntu (victim machine 1 and analysis machine): download  Ubuntu 16.10 64 bits from OsBoxes (direct\r\nlink)\r\nWindows 7 (victim machine 2): download from the Microsoft Developer Website (select IE 11 on Win 7\r\n(x86) and VirtualBox)\r\nTip: if you already have an Ubuntu virtual machine you’re not using, you can simply clone it and reuse it in the\r\nnext steps (right click \u003e Clone).\r\nBefore starting, make sure you have enough disk space available (I’d recommend at least 10-20 GB).\r\nBase Ubuntu machine\r\nOsBoxes provides us with a ready-to-go virtual disk that we can simply plug on a VM and start using right away.\r\nStart by extracting the archive you just downloaded.\r\n$ 7za e Ubuntu_16.10_Yakkety-VB-64bit.7z\r\nYou’ll be provided with a VDI file representing the virtual disk of the machine. We’ll start by setting up the base\r\nUbuntu image, which we will then clone to have our two Ubuntu VMs.\r\nhttps://blog.christophetd.fr/malware-analysis-lab-with-virtualbox-inetsim-and-burp/\r\nPage 1 of 18\n\nIn VirtualBox, create a new machine (New button), and call it Ubuntu analysis. Then, select how much RAM you\r\nwant to give it. At this point, VirtualBox will ask you if you wish to create a new virtual hard disk or use an\r\nalready exiting one. Select Use an existing virtual hard disk file, click on the directory icon at the right of the\r\ndropdown list, and select the VDI file.\r\nYou can then power up the machine. The default password is osboxes.org.\r\nBasic setup\r\nThe default keyboard uses the QWERTY layout. If like me you’re not familiar with it, start by changing it\r\n(Settings \u003e Text Entry).\r\nOptionally, you can also change the default password using:\r\n$ passwd osboxes\r\nIt can also be a good idea to update your packages.\r\n$ sudo apt-get update\r\n$ sudo apt-get upgrade\r\nInstall the guest additions\r\nSelect Devices \u003e Insert guest additions CD image in the menu of the window in which the VM runs. You will\r\nthen be asked if you want to run the installer; answer yes, and enter the default password (by default osboxes.org).\r\nOnce the installation is complete, power off the VM.\r\nCloning\r\nNow that you have a basic Ubuntu VM ready to go, clone it (right click on it in the main VirtualBox interface\r\n\u003e Clone). Name the clone Ubuntu victim, and check the checkbox to reinitialize its MAC address. Select Full\r\nclone for the type of clone.\r\nThe two Ubuntu VMs created\r\nWindows 7 machine\r\nhttps://blog.christophetd.fr/malware-analysis-lab-with-virtualbox-inetsim-and-burp/\r\nPage 2 of 18\n\nThe download link I provided earlier points to a ZIP archive containing a OVA file. Unlike a VDI file it’s not only\r\na virtual disk, but a full description of the virtual machine (including its virtual disk), so the only thing you need to\r\ndo to create a virtual machine from it is to select File \u003e Import Appliance in the main window of VirtualBox. If\r\nyou can afford it, it’s probably better to give it at least 1024 MB of RAM.\r\nOnce the import process is complete (it can take a few minutes),  rename the VM Windows 7 victim and power it\r\non.\r\nInstall the guest additions\r\nSelect Devices \u003e Insert guest additions CD image in the menu of the window in which the VM runs, and run the\r\ninstaller from the virtual CD which has been inserted. When you’re done, power off the machine.\r\n2. Setup of the analysis machine: INetSim, Burp\r\nINetSim\r\nINetSim is a very handy and powerful utility that allows to simulate a bunch of standard Internet services on a\r\nmachine. By default, it will among others emulate a DNS, HTTP and SMTP that you can easily tune. Since we’ll\r\nlater configure our victim machines to have no Internet access, we will need INetSim to simulate it.\r\nThere are several ways to install INetSim. The easiest is to run the following commands (in the analysis machine).\r\n$ sudo su\r\n$ echo \"deb http://www.inetsim.org/debian/ binary/\" \u003e /etc/apt/sources.list.d/inetsim.list\r\n$ wget -O - http://www.inetsim.org/inetsim-archive-signing-key.asc | apt-key add -\r\n$ apt update\r\n$ apt install inetsim\r\nNote: in order to be able to copy-paste those commands in your analysis machine, select Devices \u003e Shared\r\nClipboard \u003e Bidirectional.\r\nWe’ll come back later on how to use INetSim.\r\nBurp\r\nUnfortunately, it seems that INetSim’s SSL support is quite limited: it comes with a certificate for a single host\r\n(inetsim.org) and doesn’t support generating SSL certificates on the fly. This is a problem since most malwares\r\nnowadays encrypt their communications with SSL. We’ll use Burp as a transparent SSL proxy, which will stand in\r\nthe middle of the victim machines and INetSim for SSL connections. If you don’t need to intercept SSL traffic for\r\nnow, you won’t necessarily need Burp.\r\nBurp supports generating on-the-fly SSL certificates for any our victim machines will connect to. It also creates a\r\nsingle root CA certificate, that we’ll later import in our victim machines. This way, we’ll be able to intercept the\r\nencrypted communications that our malware sends.\r\nhttps://blog.christophetd.fr/malware-analysis-lab-with-virtualbox-inetsim-and-burp/\r\nPage 3 of 18\n\nYou can download Burp from the official website. The download is a bash installation script, run it to install Burp:\r\n$ bash ~/Downloads/burpsuite_free_linux_v1_7_23.sh\r\nBy default, the Burp executable will be ~/BurpSuiteFree/BurpSuiteFree.\r\n3. Setting up an isolated virtual network\r\nAs a reminder, we want to set up an isolated network containing our three VMs. This network will not be able to\r\naccess the Internet. Also, we want the analysis machine to act as a network gateway to the victim machines in\r\norder to easily be able to intercept the network traffic and to simulate various services such as DNS or HTTP.\r\nIn order to achieve this, we will use a VirtualBox Internal Network. For those familiar with VirtualBox, an internal\r\nnetwork differs from a host-only network in that an internal network cannot access the host machine at all.\r\nFor each of your three virtual machines, do the following:\r\nOpen its settings\r\nGo to the Network section\r\nChange the Attached to field to Internal network\r\nEnter malware-analysis-network as the network name\r\nNetwork configuration\r\nAnalysis machine\r\nPower on the analysis machine, open a terminal, and run the ifconfig command. You should have an interface\r\nnamed enp0s3. If the name differs, just adapt it in the instructions to follow.\r\nOpen the file /etc/network/interfaces as root, and add the following at the end:\r\nauto enp0s3\r\niface enp0s3 inet static\r\n address 10.0.0.1\r\n netmask 255.255.255.0\r\nhttps://blog.christophetd.fr/malware-analysis-lab-with-virtualbox-inetsim-and-burp/\r\nPage 4 of 18\n\nThis will assign the machine the static IP 10.0.0.1 on our virtual network. Now that we have configured the\r\nnetwork interface, we need to start it up using:\r\n$ sudo ifup enp0s3\r\nUbuntu victim machine\r\nThe process is very similar here, except that we’ll assign it the static IP 10.0.0.2, and instruct it to use 10.0.0.1 as a\r\ngateway and as a DNS server. Append the following at the end of the file /etc/network/interfaces :\r\nauto enp0s3\r\niface enp0s3 inet static\r\n address 10.0.0.2\r\n gateway 10.0.0.1\r\n netmask 255.255.255.0\r\n dns-nameservers 10.0.0.1\r\nAnd run:\r\n$ sudo ifup enp0s3\r\n$ sudo service networking restart\r\nYou should now be able to ping the analysis machine:\r\n$ ping 10.0.0.1\r\nPING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.\r\n64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.480 ms\r\n64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.526 ms\r\nWindows 7 victim machine\r\nRight-click on the network icon in the taskbar (or go to Start Menu \u003e Control Panel \u003e Network and Internet \u003e\r\nNetwork and Sharing center), click on Local Area Connection 2 \u003e Properties, select on Internet Protocol\r\nVersion 4, and click on the Properties button.\r\nWe’ll assign the static IP 10.0.0.3 to the machine, and configure the rest similarly to the Ubuntu victim machine.\r\nhttps://blog.christophetd.fr/malware-analysis-lab-with-virtualbox-inetsim-and-burp/\r\nPage 5 of 18\n\nNetwork settings\r\nMake sure to validate the settings (click on OK, Apply, etc. until all the settings windows are gone). You should\r\nnow be able to ping the analysis machine:\r\n\u003e ping 10.0.0.1\r\nPinging 10.0.0.1 with 32 bytes of data:\r\nReply from 10.0.0.1: bytes=32 time\u003c1ms TTL=64\r\nReply from 10.0.0.1: bytes=32 time\u003c1ms TTL=64\r\nAll set!\r\n4. Creating and restoring snapshots\r\nNow that our victim VMs are properly configured and are in a clean state (i.e. not infected by any kind of\r\nmalware), we are going to make a snapshot of their current state. This way, we will be able to easily reset them to\r\nthis clean state at any point time.\r\nVirtualBox makes this very easy: in the window in which the VM is running, just select Machine \u003e Take\r\nSnapshot. You can name the snapshot Clean state. Make sure to do this for both your Ubuntu and Windows 7\r\nvictim machines. It doesn’t hurt to do it for your analysis machine as well.\r\nhttps://blog.christophetd.fr/malware-analysis-lab-with-virtualbox-inetsim-and-burp/\r\nPage 6 of 18\n\nWhen you’ll want to reset a machine to its clean state, simply power it off and check the checkbox Restore\r\ncurrent snapshot ‘Clean state’.\r\n5. Using INetSim and Burp on the analysis machine to analyze the network traffic\r\nINetSim\r\nAs previously mentioned, INetSim enables us to wide range of standard Internet services including DNS,\r\nHTTP(S), SMTP, etc. It has a default configuration file /etc/inetsim/inetsim.conf which is very well documented.\r\nIt also ships with a data directory (/var/lib/inetsim) containing various default files.\r\nSince you’ll probably want a different INetSim configuration each time you make a new analysis, I suggest you\r\ncreate a directory analysis which will contain a sub directory for each analysis.\r\n$ mkdir analysis\r\nWe’ll already create a sub directory for the sake of example, and copy the default INetSim configuration file and\r\ndata folder in it.\r\n$ mkdir analysis/test-analysis\r\n$cp /etc/inetsim/inetsim.conf analysis/test-analysis\r\n$ sudo cp -r /var/lib/inetsim analysis/test-analysis/data\r\n$ sudo chmod -R 777 data\r\n$ cd analysis/test-analysis\r\nBy default, INetSim listens on the local interface only. To make it available to all the machines of our virtual\r\nnetwork, replace the following line in the configuration file we just copied:\r\n#service_bind_address  10.0.0.1\r\nBy:\r\nhttps://blog.christophetd.fr/malware-analysis-lab-with-virtualbox-inetsim-and-burp/\r\nPage 7 of 18\n\nservice_bind_address 0.0.0.0\r\nNow, we need to disable systemd-resolved, which is a local DNS server shipped by default with Ubuntu and will\r\nconflict with INetSim’s DNS server.\r\n$ sudo systemctl disable systemd-resolved.service\r\n$ sudo service systemd-resolved stop\r\nBy default, INetSim’s DNS server will resolve all the domain names to 127.0.0.1. We want any domain name to\r\nresolve to 10.0.0.1 (the analysis machine IP) instead; uncomment the following line:\r\n#dns_default_ip 10.0.0.1\r\nI mentioned earlier that INetSim’s SSL support is not optimal since it only has a single certificate for a single\r\nhostname (inetsim.org) and doesn’t allow to generate per-host certificates on the fly. To overcome that, we’ll run\r\nBurp on port 443 as a transparent proxy in front of INetSim. Therefore, we need to bind INetSim’s HTTPS server\r\nto a different port, say port 8443. Replace the following line:\r\n#https_bind_port 443\r\nBy:\r\nhttps_bind_port 8443\r\nNow, let’s run INetSim!\r\n$ sudo inetsim --data data --conf inetsim.conf\r\nINetSim 1.2.6 (2016-08-29) by Matthias Eckert \u0026 Thomas Hungenberg\r\n[...]\r\n=== INetSim main process started (PID 3605) ===\r\nSession ID: 3605\r\nListening on: 0.0.0.0\r\nReal Date/Time: 2017-06-04 12:58:07\r\nFake Date/Time: 2017-06-04 12:58:07 (Delta: 0 seconds)\r\n Forking services...\r\n * dns_53_tcp_udp - started (PID 3621)\r\n * irc_6667_tcp - started (PID 3631)\r\n * daytime_13_tcp - started (PID 3638)\r\n * discard_9_tcp - started (PID 3642)\r\n * discard_9_udp - started (PID 3643)\r\n * ident_113_tcp - started (PID 3634)\r\nhttps://blog.christophetd.fr/malware-analysis-lab-with-virtualbox-inetsim-and-burp/\r\nPage 8 of 18\n\n* syslog_514_udp - started (PID 3635)\r\n[...]\r\nAs you can see, INetSim has launched a bunch of network services. Those are all configurable and can be disabled\r\nin the configuration file. This configuration file is very well documented and explains all the options of INetSim; I\r\nrecommend you take a few minutes to read it.\r\nNow, power on of your victim VM, open a web browser, and browse to any address (e.g. github.com).  You should\r\nsee the following:\r\n(Note that this default file corresponds to the HTML file data/http/fakefiles/sample.html.)\r\nBack on the analysis machine, shut down INetSim (CTRL + C).\r\n* dns_53_tcp_udp - stopped (PID 3621)\r\n* irc_6667_tcp - stopped (PID 3631)\r\n* daytime_13_tcp - stopped (PID 3638)\r\n[...]\r\nhttps://blog.christophetd.fr/malware-analysis-lab-with-virtualbox-inetsim-and-burp/\r\nPage 9 of 18\n\nSimulation stopped.\r\n Report written to '/var/log/inetsim/report/report.3877.txt' (24 lines)\r\nAs you can see, INetSim has created a summary report for us. It contains all the interactions our victim machine\r\nhad with INetSim services.\r\n=== Report for session '3877' ===\r\nReal start date : 2017-06-04 13:18:27\r\nSimulated start date : 2017-06-04 13:18:27\r\nTime difference on startup : none\r\n2017-06-04 13:18:38 First simulated date in log file\r\n2017-06-04 13:18:40 DNS connection, type: A, class: IN, requested name: github.com\r\n2017-06-04 13:18:40 HTTP connection, method: GET, URL: http://github.com/, file name: data/http/fakef\r\n2017-06-04 13:18:40 HTTP connection, method: GET, URL: http://github.com/favicon.ico, file name: data\r\n2017-06-04 13:18:40 Last simulated date in log file\r\nBurp for SSL interception\r\nTo be able to analyze the SSL traffic, we also need to run Burp. We’ll run it as a transparent proxy in front of\r\nINetSim. When a victim machine will initiate a SSL connection, it will first go to Burp, which will then proxy it to\r\nINetSim. This section is not mandatory: if you don’t need to intercept SSL traffic right now, just jump to the next\r\nsection.\r\nHere’s how it will look like with Burp in the middle:\r\nStart Burp as root:\r\n$ sudo /home/osboxes/BurpSuiteFree/BurpSuiteFree\r\nhttps://blog.christophetd.fr/malware-analysis-lab-with-virtualbox-inetsim-and-burp/\r\nPage 10 of 18\n\n(We need to run it as root otherwise it won’t be able to bind port 443, which is a privileged port. There are other\r\nways to do this, but let’s not bother here)\r\nCreate a temporary project (you don’t have any other options with the free version anyway), and go to the Proxy\r\ntab, then to the Options sub-tab. You’ll see Burp’s default listener listening on port 8080.\r\nClick on the row corresponding to the default listener, and edit it (Edit) button. Configure it as follows:\r\nBinding tab\r\nBind to port: 443\r\nBind to address: all interfaces\r\nRequest handling tab:\r\nRedirect to host: localhost\r\nRedirect to port: 8443\r\nCheck Support invisible proxying\r\nValidate the settings, and you should get a listener similar to:\r\nBy default, Burp intercepts the incoming requests and waits for you to explicitly let them pass through. To avoid\r\nthis, go to the Intercept tab and click the button Intercept is on to disable it.\r\nSince Burp Free doesn’t allow you to save a project, you can export the settings we just made in order to import\r\nthem next time you start Burp. To do this, use Burp \u003e Project options \u003e Save project options.\r\nhttps://blog.christophetd.fr/malware-analysis-lab-with-virtualbox-inetsim-and-burp/\r\nPage 11 of 18\n\n---\ntitle: INetSim default HTML page\n---\nLet’s make sure our setup if correctly working. Start INetSim, and run:\n$ curl --insecure https://localhost\nYou should get:\n\nThis is the default HTML page for INetSim HTTP server fake mode.\n\nThis file is an HTML document.\n\nImporting Burp’s CA certificate on our victim machines\nPower on your Windows 7 victim machine, and try to browse to a HTTPS URL (e.g. https://github.com), you’ll\nsee a warning similar to:\nThis is because Burp generates a SSL certificate signed by its own CA certificate, which our victim machine\ndoesn’t trust for now.\nIn Burp, add a new proxy listener on port 8080, listening on all interfaces (tab Proxy \u003e Options \u003e button Add):\nhttps://blog.christophetd.fr/malware-analysis-lab-with-virtualbox-inetsim-and-burp/\nPage 12 of 18\n\nThen, from the victim machine, browse to http://10.0.0.1:8080.\r\nClick on CA Certificate in the top-right corner to download Burp’s CA certificate.\r\nOn the Windows 7 victim machine: open the file, click Install certificate \u003eNext \u003e Place all certificates in the\r\nfollowing store: Trusted Root Certification Authorities \u003e Next\r\nOn the Ubuntu victim machine:\r\nConvert the certificate to the appropriate format (.crt) using\r\n$ openssl x509 -in ~/Downloads/cacert.der -inform DER -out burp.crt\r\nCopy it to /usr/local/share/ca-certificates\r\n$ sudo cp burp.crt /usr/local/share/ca-certificates/\r\nRun\r\n$ sudo update-ca-certificates\r\nFirefox by default doesn’t use the system’s certificate store. If you want the SSL connection to work\r\nproperly in Firefox as well, go to the Firefox settings into Advanced \u003e Certificates \u003e Import.\r\nChoose burp.crt, check Trust this CA to identify websites\r\nAll set!\r\nhttps://blog.christophetd.fr/malware-analysis-lab-with-virtualbox-inetsim-and-burp/\r\nPage 13 of 18\n\nOnce you imported Burp’s CA certificate in the victim machines, make sure to create a new snapshot (e.g. Clean\r\nstate with Burp’s CA certificate installed).\r\n6. Setting up a shared folder between the analysis machine and the host OS\r\nAt some point, you’ll obviously want to transfer some files to the analysis machine or to one of the victim\r\nmachine; we’ll set up a file share to achieve it.\r\nIn the VirtualBox running the analysis machine, go to Devices \u003e Shared Folders \u003e Shared folders settings.\r\nCreate a new shared folder, choose the local folder of your host OS it should be mapped to, and choose a name.\r\nCheck the checkbox to make it permanent.\r\nNow on the analysis machine, mount the shared folder:\r\n$ mkdir ~/malware-analysis-share\r\n$ sudo mount -t vboxsf -o uid=$UID,gid=$(id -g) malware-analysis-share ~/malware-analysis-share\r\nAnd you’re good to go. In my case, all the files of my host machine located in /home/christophetd/malware-analysis-share will also end up in ~/malware-analysis-share in the analysis machine.\r\nTransferring files to a victim machine\r\nhttps://blog.christophetd.fr/malware-analysis-lab-with-virtualbox-inetsim-and-burp/\r\nPage 14 of 18\n\nAt some point, you’ll most probably need to transfer some files (e.g. malware samples) to one of the victim\r\nmachines. Setting up a file share for them is a bad idea, because it means the victim machine (and by extent, the\r\nmalware sample you’re running on it) have access to it.\r\nThe simplest way to achieve a file transfer to the Ubuntu victim machine is to use netcat. Here’s a quick example.\r\n# Receiving machine having IP 10.0.0.2\r\n$ nc -lvp 4444 \u003e file.exe\r\n# Analysis machine (sender)\r\n$ cat file_to_transfer.exe | nc 10.0.0.2 4444\r\nFor a Window victim, we unfortunately don’t have netcat available. Alternatives might exist, but they probably\r\ndon’t ship by default. One option is to use INetSim to serve your file to the victim machine.\r\n# inetsim.conf\r\n# Remove the default line: http_fakefile      exe   sample_gui.exe x-msdos-program\r\n# Replace it by\r\nhttp_fakefile      exe   file_to_transfer.exe x-msdos-program\r\n# And put file_to_transfer.exe in ./data/http/fakefiles\r\nWith this of configuration, just browse any URL ending with a ‘.exe’ (e.g. http://github.com/file.exe).\r\n7. Demo time: the TeslaCrypt ransomware\r\nTime for a quick demo! I downloaded a sample of the ransomware TeslaCrypt, transferred it to our Windows 7\r\nvictim machine, and executed  it. After a few seconds, all the files of the VM have been encrypted and the\r\nfollowing window pops-up.\r\nhttps://blog.christophetd.fr/malware-analysis-lab-with-virtualbox-inetsim-and-burp/\r\nPage 15 of 18\n\nTeslaCrypt main window (click for full-size image)\r\nhttps://blog.christophetd.fr/malware-analysis-lab-with-virtualbox-inetsim-and-burp/\r\nPage 16 of 18\n\nThe machine’s files have been encrypted and replaced by files with the ECC extension\r\nAfter checking the logs of INetSim, we can see that the ransomware did the following DNS lookups:\r\n7tno4hib47vlep5o.tor2web.org\r\n7tno4hib47vlep5o.tor2web.blutmagie.de\r\n7tno4hib47vlep5o.tor2web.fi\r\nbitcoin.toshi.io\r\nAnd sent several HTTP requests to those domains.\r\nHTTPS connection, method: GET, URL: https://7tno4hib47vlep5o.tor2web.org/state.php?U3ViamVjdD1QaW5nJm\r\nHTTPS connection, method: GET, URL: https://7tno4hib47vlep5o.tor2web.blutmagie.de/state.php?U3ViamVjd\r\nHTTPS connection, method: GET, URL: https://7tno4hib47vlep5o.tor2web.fi/state.php?U3ViamVjdD1QaW5nJmt\r\nHTTPS connection, method: GET, URL: https://bitcoin.toshi.io/api/v0/addresses/1LNUF3BqL3ob1CT2aVp3cW4\r\nWe see similar requests are made to tor2web.org, tor2web.blutmagie.de and tor2web.fi. Those services allow to\r\naccess the Tor network without having to install Tor Browser or a similar tool.\r\nThe malware contacts the Tor hidden service 7tno4hib47vlep5o.onion, which is probably some kind of C\u0026C\r\nserver. The payload of the request is a base64 encoded string, which decodes to:\r\nSubject=Ping\r\n\u0026key=15B38B18AF20C0DB2A7C771E014363F2CB8781B156D519CC5F220335D4714AA3\r\n\u0026addr=1LNUF3BqL3ob1CT2aVp3cW4Nb8zkkViVwT\r\n\u0026files=0\r\n\u0026size=0\r\n\u0026version=0.2.6a\r\n\u0026date=1496648675\r\n\u0026OS=7601\r\n\u0026ID=16\r\n\u0026subid=0\r\n\u0026gate=G1\r\nIt also makes an API call to bitcoin.toshio.io (which doesn’t exist anymore), most probably to check if the ransom\r\nhas been paid to the bitcoin address 1LNUF3BqL3ob1CT2aVp3cW4Nb8zkkViVwT. It seems like the malware\r\ngenerates an unique bitcoin address for each infected computer, since the address didn’t receive or send out any\r\nmoney.\r\nConclusion\r\nHopefully this guide will be helpful and allow you to safely analyze the network interactions of a malware. Keep\r\nin mind that some malwares detect when they are being run in a virtual machine and might adapt their behavior\r\n(e.g. do nothing). Here’s an article from MalwareBytes on the subject.\r\nhttps://blog.christophetd.fr/malware-analysis-lab-with-virtualbox-inetsim-and-burp/\r\nPage 17 of 18\n\nAlso, remember that while analyzing a malware’s network traffic can be very useful, it’s only one kind of dynamic\r\nanalysis. Others include monitoring the register, the system calls, the files opened / created, etc. Open Security\r\nTraining offers a full hands-on course on the topic, for free.\r\nDon’t hesitate to leave a comment if you found this guide useful / awesome / too long / too detailed. A big thank\r\nyou to lbarman for the proofreading and numerous suggestions.\r\nStay safe!\r\nLiked this post? Show it by pushing the heart button below! You can also follow me on Twitter.\r\n+16\r\nSource: https://blog.christophetd.fr/malware-analysis-lab-with-virtualbox-inetsim-and-burp/\r\nhttps://blog.christophetd.fr/malware-analysis-lab-with-virtualbox-inetsim-and-burp/\r\nPage 18 of 18",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://blog.christophetd.fr/malware-analysis-lab-with-virtualbox-inetsim-and-burp/"
	],
	"report_names": [
		"malware-analysis-lab-with-virtualbox-inetsim-and-burp"
	],
	"threat_actors": [
		{
			"id": "08c8f238-1df5-4e75-b4d8-276ebead502d",
			"created_at": "2023-01-06T13:46:39.344081Z",
			"updated_at": "2026-04-10T02:00:03.294222Z",
			"deleted_at": null,
			"main_name": "Copy-Paste",
			"aliases": [],
			"source_name": "MISPGALAXY:Copy-Paste",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775439121,
	"ts_updated_at": 1775826685,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/a00e0f1c92675875e7563d3b847e91cd96dd7306.pdf",
		"text": "https://archive.orkl.eu/a00e0f1c92675875e7563d3b847e91cd96dd7306.txt",
		"img": "https://archive.orkl.eu/a00e0f1c92675875e7563d3b847e91cd96dd7306.jpg"
	}
}