Interesting to note:
(S) Elsa currently makes no provisions for automatically beaconing or
exfiltrating collected data off of the target machine. Therefore the
operator must extract the Elsa log file from the target machine
through other means.
Otherwise, the same way you would check anything else:
Compare known checksums of the variants of the malware against all files on the hard drive. CIA could potentially use some kind of crypter or other obfuscation of this malware - but they also may not have since the population of targets was probably very low.
Use Autoruns from Microsoft's TechNet site on another computer to examine an offline image/disk of a suspected infected system. ELSA does not appear to be very advanced, so its persistence across reboots relies on very visible techniques like startup tasks/boot time loading of modules.
a. Use known good checksums/digital signatures while examining any items launching alongside the OS.
b. Validate that only programs and drivers from known publishers, whose digital signatures are intact, are loading. If an unsigned file is loaded by a signed file, this is a big and often non-obvious attack surface. Compare the unsigned file against the version published by the manufacturer.
Monitor network traffic of a system for connections to Google's Location Services while no other applications are generating traffic. Since ELSA uses these 3rd party geolocation APIs to generate its logging, it will likely connect to these services at certain intervals. You can probably fully disable the use of these services in your browsers' settings and use the browser normally while watching for these connections, in case ELSA tries to only obtain this information while there is some sort of other traffic being generated by the host.