{ "id": "c460fd4c-d3fd-474c-b216-caf49919819f", "created_at": "2026-04-06T00:13:18.664732Z", "updated_at": "2026-04-10T03:34:57.329683Z", "deleted_at": null, "sha1_hash": "fe7bc46babd458836f527acf29e40db8df2ba5b4", "title": "CERN Computer Security Information", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 58851, "plain_text": "CERN Computer Security Information\r\nArchived: 2026-04-05 21:38:33 UTC\r\n2019/06/04 Advisory: Windigo attacks\r\nThis page covers ongoing attacks and may be updated (latest: 2019-07-17).\r\nIntroduction\r\nWindigo has been a long-standing adversary of the Research \u0026 Education community. The first known attack\r\ndates back to 2011, when the Ebury malware was discovered during the Linux Foundation attack in 2011 . A\r\ntechnical paper describing the attacks in-depth was published in 2014 by ESET: \"Operation Windigo\" . After the\r\narrest and conviction of one of the key attackers, our community observed a sharp drop in the number of\r\ninfections. Sporadic Ebury infections continued to be observed in other sectors and led to another update from\r\nESET: Windigo Still not Windigone: An Ebury Update . A lot could be learnt from the attacks to better protect\r\nour community, for example to detect OpenSSH backdoors .\r\nUnfortunately, dozens of Linux servers were discovered compromised again in the Research \u0026 Education\r\ncommunity in May 2019, all running new and improved versions of Ebury.\r\nEbury malware\r\nThe Ebury malware samples detected in May 2019 appear to be evolutions of the malicious code from 2014 and\r\n2017. The technical documents referenced in the introduction remain largely valid. In a nutshell, the Ebury\r\nmalware replaces legitimate dynamic libraries (e.g. libkeyutils.so) in the affected system to capture SSH\r\npasswords and SSH keys. When executed:\r\nThe infected dynamic library will load a secondary malicious dynamic library (e.g. libstz.so), containing\r\nthe actual malicious code;\r\nMalicious hooks and a specific OpenSSH server configuration are pushed within the running OpenSSH\r\nserver binary to accomodate the capture of credentials and backdoor functionality;\r\nA malicious process is forked and dedicated to the extraction of credentials;\r\nThe two malicious processes communicate via an abstract unix socket.\r\nEbury backdoor\r\nEbury uses a complex backdoor mechanism described in the technical documents referenced in the introduction.\r\nIn the samples collected in May 2019, the authentication part of the backdoor was updated and reinforced.\r\nNevertheless, the attacker seem to continue to connect daily to infected hosts and exfiltrate the credentials using\r\nknown techniques.\r\nIndicators of compromises\r\nhttps://security.web.cern.ch/security/advisories/windigo/windigo.shtml\r\nPage 1 of 3\n\nNetwork: Backdoor connections\r\nThe attacker is known to use direct incoming SSH connections to the victims OpenSSH server. The backdoor\r\nconnection will be regular SSH connections, with two notable exceptions:\r\nThe SSH client string will be different: SSH-2.0-XXXXXXXXXXXXXXX, where\r\nXXXXXXXXXXXXXXX will either be a Hex number (Ebury \u003c 1.7.0) or Base64 string (Ebury \u003e= 1.7.0);\r\nThe string is an encrypted message for the backdoor. It can be decoded based on the incoming IP address\r\nused by the attacker;\r\nLogging all incoming SSH client versions using network monitoring tools is very helpful.\r\nExample malicious strings from incoming IP address 80.82.67.21: SSH-2.0-\r\n1f25412f1c4d340d173f003a35150d5734111a5562471c.\r\nBackdoor connections (incoming SSH) may be observed form the following IP addresses:\r\n94.140.120.163\r\n49.50.70.223\r\n80.82.67.21\r\n125.160.17.32\r\nIt is essential to monitor the SSH client version string.\r\nNetwork: Password exfiltration\r\nThe SSH client string is decrypted by the client to reveal the credentials exfiltration IP address that needs to be\r\nused by the malware. Both the SSH client string and the incoming IP address are needed to decrypt the\r\nmalicious command and exfiltration IP address.\r\nThe exfiltration IP address is used by the malware to exfiltrate captured credentials as a outgoing DNS request\r\n(UDP:53). The following IP address has been identified as the exfiltration (outgoing UDP:53) host: 91.236.116.62\r\nAdditional exfiltration methods are described in the technical documents referenced in the introduction. In\r\nparticular, the malware also relies on a DGA, and the attacker seems to have prepared the following domains:\r\nlarfj7g1vaz3y.net / 78.140.134.7.\r\nop3f1libgh.biz / 193.0.179.76.\r\nThese domains are actively maintained by the attacker. However, no known affected host has been observed using\r\nthis exfiltration path in the current attack.\r\nHost-based indicators\r\nThe easiest way to inspect the OpenSSH server for signs of infection is to verify the dynamic libraries in use. In\r\nparticular, libkeyutils.so.* will typically have a single link to libc.so. Note that the malware uses different library\r\nfilenames (e.g. libsbz.so, libstz.so, etc.). For example, on an infected system:\r\nhttps://security.web.cern.ch/security/advisories/windigo/windigo.shtml\r\nPage 2 of 3\n\n# objdump -x /lib64/libkeyutils.so.1|grep NEEDED\r\nNEEDED libc.so.6\r\nNEEDED libstz.so\r\nThis indicates that libkeyutils.so.1 has been infected and will call Ebury from libstz.so. This contrasts with a clean\r\nsystem:\r\n# objdump -x /lib64/libkeyutils.so.1 |grep NEEDED\r\nNEEDED libc.so.6\r\nDue to code errors in the malware, it is also common to discover segfault messages in the kernel logs, for\r\nexample:\r\nJun 04 09:01:03 hostname kernel: sshd[12345]: segfault at 7fcf794b8000 ip 00007fcf792a50b8 sp\r\n00007fffb6b8e0e0 error =\r\nThe malicious abstract unix socket may also be identified by running the following command:\r\n# lsof |grep \"@/run\"\r\nNote: as it is an abstract socket, it is not possible to find it on the filesystem.\r\nResponding to the attack\r\nThe attack is relying on stolen SSH credentials in our highly interconnected community. Therefore the initial\r\ninfection vector is often a valid SSH login from a valid user from a known location.\r\nAs a result, collaboration between the affected organizations is absolutely crucial. Responding to this attack\r\nextensively relies on victims reporting attacks and contributing new malicious samples, and sharing back with the\r\ncommunity. If you are affected by this attack, you can:\r\nAsk directly for advice or support to cert@cern.ch;\r\nShare with or without attribution malicious samples and indicators of compromise with cert@cern.ch.\r\nSource: https://security.web.cern.ch/security/advisories/windigo/windigo.shtml\r\nhttps://security.web.cern.ch/security/advisories/windigo/windigo.shtml\r\nPage 3 of 3", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://security.web.cern.ch/security/advisories/windigo/windigo.shtml" ], "report_names": [ "windigo.shtml" ], "threat_actors": [ { "id": "1934b371-2525-4615-a90a-772182bc4184", "created_at": "2022-10-25T15:50:23.396576Z", "updated_at": "2026-04-10T02:00:05.341979Z", "deleted_at": null, "main_name": "Windigo", "aliases": [ "Windigo" ], "source_name": "MITRE:Windigo", "tools": [ "Ebury" ], "source_id": "MITRE", "reports": null }, { "id": "3844202f-b24a-4e16-b7b9-dfe8c0a44d5d", "created_at": "2022-10-25T16:07:24.526179Z", "updated_at": "2026-04-10T02:00:05.023222Z", "deleted_at": null, "main_name": "Operation Windigo", "aliases": [ "G0124" ], "source_name": "ETDA:Operation Windigo", "tools": [ "CDorked", "CDorked.A", "Calfbot", "Ebury" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434398, "ts_updated_at": 1775792097, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/fe7bc46babd458836f527acf29e40db8df2ba5b4.pdf", "text": "https://archive.orkl.eu/fe7bc46babd458836f527acf29e40db8df2ba5b4.txt", "img": "https://archive.orkl.eu/fe7bc46babd458836f527acf29e40db8df2ba5b4.jpg" } }