A Comparison of Trojan Virus Behavior in Linux and Windows Operating Systems

Trojan virus attacks pose one of the most serious threats to computer security. A Trojan horse is typically separated into two parts - a server and a client. It is the client that is cleverly disguised as significant software and positioned in peer-to-peer file sharing networks, or unauthorized download websites. The most common means of infection is through email attachments. The developer of the virus usually uses various spamming techniques in order to distribute the virus to unsuspecting users. Malware developers use chat software as another method to spread their Trojan horse viruses such as Yahoo Messenger and Skype. The objective of this paper is to explore the network packet information and detect the behavior of Trojan attacks to monitoring operating systems such as Windows and Linux. This is accomplished by detecting and analyzing the Trojan infected packet from a network segment -which passes through email attachment- before attacking a host computer. The results that have been obtained to detect information and to store infected packets through monitoring when using the web browser also compare the behaviors of Linux and Windows using the payload size after implementing the Wireshark sniffer packet results. Conclusions of the figures analysis from the packet captured data to analyze the control bit, and check the behavior of the control bits, and the usability of the operating systems Linux and Windows.

💡 Research Summary

The paper investigates the behavior of Trojan horse malware transmitted via email attachments on two major operating systems, Linux (Ubuntu) and Windows 7. The authors selected two representative malicious payloads—a “hp‑ftp.exe” file representing a typical Trojan horse and a “backdoor.exe” file representing a backdoor Trojan. Both files were attached to emails and delivered to test machines in a controlled network environment.

Packet capture was performed using Wireshark and a custom packet sniffer built on libpcap. Captured traffic was logged at the Ethernet, IP, TCP, and application layers, with payload data displayed in both hexadecimal and ASCII formats. The analysis proceeded in four stages: (1) verification of MAC and IP addresses, (2) inspection of TCP flags and sequence numbers for anomalous connection attempts, (3) examination of payload size, content, and transmission patterns, and (4) storage of extracted metadata for web‑based visualization.

Results showed distinct differences between the two operating systems. On Windows, the Trojan horse transmitted the 14 140‑byte “hp‑ftp.exe” file with minimal alteration of TCP flags, making it difficult for conventional IDS/IPS solutions to flag the traffic. Some packets, however, displayed encrypted payload fragments, indicating a subtle obfuscation step. In contrast, the same file on Linux exhibited abnormal TTL reductions and occasional encrypted payload insertion, suggesting that Linux’s network stack or firewall (iptables) responded differently to the malicious traffic.

The backdoor payload behaved similarly on both platforms: the transmitted payload appeared empty, reflecting the backdoor’s strategy of opening a remote control channel without sending substantive data. Nevertheless, Linux logs captured more evidence of the backdoor’s activity than Windows logs, implying a higher visibility of post‑infection actions on Linux.

The authors attribute these discrepancies to differences in OS network stack implementations and default security mechanisms (e.g., Windows Defender vs. iptables). They propose that a combination of payload size thresholds and specific TCP flag patterns could serve as effective signatures for detecting Trojan activity across platforms.

However, the study has notable limitations. The sample set is small, consisting of only two malware variants, and no extensive testing of multiple variants or repeated runs was performed, limiting statistical confidence. The capture configuration toggled between promiscuous and non‑promiscuous modes, yet the impact of this switch on detection rates was not quantitatively analyzed. Additionally, filter settings, buffer sizes, and other sniffer parameters were not rigorously controlled, potentially affecting the reproducibility of results.

In conclusion, the paper provides a practical demonstration of packet‑level analysis for Trojan detection on Linux and Windows, highlighting observable behavioral differences that can inform signature‑based detection strategies. Future work should expand the malware corpus, incorporate a broader range of operating systems, and explore machine‑learning approaches that leverage the captured packet features for more robust, adaptive malware detection.