Information Security News
by Sean Gallagher
A Top Secret NSA analyst's report published by The Intercept suggests that, in August 2016, the Russian General Main Staff Intelligence Directorate (GRU) hacked into an election-related hardware and software vendor in the US. The GRU then used data from the company for at least two "spear phishing" campaigns against local government officials associated with elections—including one attack close to the election that appeared to target officials dealing with absentee ballots. The report was based on information that only became available in April of this year, and the NSA report does not reveal the name of the company.
Within an hour of the story's publication, the FBI announced the arrest of the alleged source of the leaked report. Reality Leigh Winner was arrested at home in Augusta, Georgia, after an NSA audit identified her as the person who printed and removed the report from a secure facility. The Intercept had turned over a copy of the report to the NSA to verify its provenance while asking for comment. After analysis of the document showed that it had been folded up, suggesting it had been printed, the NSA determined only six employees had access to the document, and only Winner had been in e-mail contact with The Intercept.
Seven e-mail accounts at the vendor company were targeted with a method similar to the one that obtained access to e-mail accounts used by members of the Clinton campaign earlier in 2016, according to the text of the report. At least one of those accounts appears to have been compromised, as information from the company was then used in two separate sets of e-mails with malicious attachments sent to election officials just days before the election.
Malware authors often encode their malicious payload, to avoid detection and make analysis more difficult.
I regurlarly see payloads encoded with the XOR function. Often, they will use a sequence of bytes as encoding key. For example, lets take Password as encoding key. Then the first byte of the payload is XORed with the first byte of the key (P), the second byte of the payload is XORed with the second byte of the key (a), and so on until all bytes of the key have been used. And then we start again with the first byte of the key: the ninth byte of the payload is XORed with the first byte of the key (P), ...
Let width:889px" />
So just by opening a XOR encoded PE file with a binary editor, we can see the repeating key, provided that the key is smaller than the sequences of 0x00 bytes.
Second interesting property of the XOR function: if you XOR the original file (cleartext) with the encoded file (ciphertext), you get the key (or to be more precise, the keystream).
Lets take another example. We know that in many PE files, you can find the string This program can not be run in DOS mode. width:882px" />
So if we have the encoded file, and the partially unencoded file, we can also recover the key, provided again that the key is smaller than the unencoded text, and that we know where to line-up the encoded and unencoded text.
In a next diary entry, I will show a tool to automate this analysis process.