In this section we document the outcomes of more detailed inspection of both the communication mechanisms (JavaScript, JAR, swf) and HTML that might help to better fingerprint the websites.
There are four main types of communication mechanisms found:
  • There is also one known instance where a .zip extension was used! web.archive.org/web/20131101104829*/http://plugged-into-news.net/weatherbug.zip as:
    <applet codebase="/web/20101229222144oe_/http://plugged-into-news.net/" archive="/web/20101229222144oe_/http://plugged-into-news.net/weatherbug.zip"
    JAR is the most common comms, and one of the most distinctive, making it a great fingerprint.
    Several of the JAR files are named something like either:
    as if to pose as Internet speed testing tools? The wonderful subtleties of the late 2000s Internet are a bit over our heads.
    All JARs are directly under root, not in subdirectories, and the basename usually consist of one word, though sometimes two camel cased.
  • JavaScript file. There are two subtypes:
    • JavaScript with SHAs. Rare. Likely older. Way more fingerprintable.
    • JavaScript without SHAs. They have all been obfuscated slightly different and compressed. But the file sizes are all very similar from 8kB to 10kB, and they all look similar, so visually it is very easy to detect a match with good likelyhood.
  • Adobe Flash swf file. In all instances found so far, the name of the SWF matches the name of the second level domain exactly, e.g.:
    http://tee-shot.net/tee-shot.swf
    While this is somewhat of a fingerprint, it is worth noting that is was a relatively commonly used pattern. But it is also the rarest of the mechanisms. This is a at a dissonance with the rest of the web, which circa 2010 already had way more SWF than JAR apparently.
    Some of the SWF websites have archives for empty /servlet pages:
    ./bailsnboots.com/20110201234509/servlet/teammate/index.html
./currentcommunique.com/20110130162713/servlet/summer/index.html
./mynepalnews.com/20110204095758/servlet/SnoopServlet/index.html
./mynepalnews.com/20110204095403/servlet/release/index.html
./www.hassannews.net/20101230175421/servlet/jordan/index.html
./zerosandonesnews.com/20110209084339/servlet/technews/index.html
    which makes us think that it is a part of the SWF system.
  • CGI comms
These have short single word names with some meaning linked to their website.
Because the communication mechanisms are so crucial, they tend to be less varied, and serve as very good fingerprints. It is not ludicrous, e.g. identical files, but one look at a few and you will know the others.
We've come across a few shallow and stylistically similar websites on suspicious ranges with this pattern.
No JS/JAR/SWF comms, but rather a subdomain, and an HTTPS page with .cgi extension that leads to a login page. Some names seen for this subdomain:
  • secure.: most common
  • ssl.: also common
  • various other more creative ones linked to the website theme itself, e.g.:
    • musical-fortune.net has a backstage.musical-fortune.net
The question is, is this part of some legitimate tooling that created such patterns? And if so which? Or are they actual hits with a new comms mechanism not previously seen?
The fact that:
  • hits of this type are so dense in the suspicious ranges
  • they are so stylistically similar between on another
  • citizenlabs specifically mentioned a "CGI" comms method
suggests to Ciro that they are an actual hit.
In particular, the secure and ssl ones are overused, and together with some heuristics allowed us to find our first two non Reuters ranges! Section "secure subdomain search on 2013 DNS Census"
The CGI comms websites contain the only occurrence of HTTPS, so it might open up the door for a certificate fingerprint as proposed by user joelcollinsdc at: news.ycombinator.com/item?id=36280801!
crt.sh appears to be a good way to look into this:
They all appear to use either of:
Let's try another one for secure.altworldnews.com: search.censys.io/certificates/e88f8db87414401fd00728db39a7698d874dbe1ae9d88b01c675105fabf69b94. Nope, no direct mega hits here either.
This project was originally done before Ciro Santilli knew how to use Codex and before Codex was so incredibly strong. Codex 6 Astra High can now just disassemble, deobfuscate and datamine the fuck out of such binaries, so we asked it to. Unfortunately it couldn't really find anything mind blowing, but here are the results anyways.
The analysis scripts is: jar.py and it should be pointed to a dump directory of the websites such as CIA 2010 websites dump. The analysis below was done as of commit b9eb31618c36421133e4875bc1cd7d7ac7763a32.
These scripts produce TODO directories.
The JARs are obfuscated, and Codex believes that they have a strong match to the Zelix KlassMaster commercial obfuscator, and points to this analysis from 2006: www.exploit-db.com/docs/english/13132-cracking-string-encryption-in-java-obfuscated-bytecode.pdf. Zelix appears to have the exact same string obfucation mechanism quat1024 had already previously manually discovered. It stores all string literals XOR'ed with 5 consecutive key bytes along:
switch (character_index % 5):
    case 0: key = 47
    case 1: key = 41
    case 2: key = 84
    case 3: key = 35
    default: key = 14
It then injects an encoder/decoder for this which transforms the strings as neede at runtime. The bytes are present in each class file itself.
Zelix is made by an Australian company based in Narraweena and its website proudly sates:
Leading Java Obfuscator since 1997
Shame they failed to list the CIA in their users list! I'm goign to ping them actually.
Here are the best small finds:
  • some of the resource/resources.bin files contain the string:
    #Auto-generated Starbuck client config file
    Codex could not find any clear public reference to what Starbuck is, which leads to the tentalizing possibility that could be an internal project codename. Though the possibility that it is just some internal of some public tool so obscure that even the web has lost track of it is also too strong to refute entirely.
    This string is part of a more complete key/value pair, e.g. dryterrainnews.com contains:
    • key: Config.properties.old.1277148810409
    • value:
      #Auto-generated Starbuck client config file: Mon Jun 21 14:32:02 ACT 2010
#Mon Jun 21 14:32:02 ACT 2010
ServerURL=http\\://www.dryterrainnews.com/cgi-bin/nigeria.cgi
EncSharedSecret=7A948986EF08B9DDF800E5AF229EC118D4F8AD9609C5080CBF2AB92397C2A9B8
KeyE=1F7D7
KeyN=67D8EA7BF935232E55863DCED7A279F701B7492316FE96F15D00C983CBFDB93B97D35898FA8928FA13D4F320E2B62D1B92F08FA8692F7D043EC197E2857D2A540E01A2529AEB232EB386917992B80D5CADE283D2C4E8DCBF682704F419E29D013FFCF33D9A1BC94E4AA469058BB508EEE1D654CF9FC4B89977A13FA33CDEDAED
    which would be present insie the resource/resources.bin file present inside the JAR.
    resource/resources.bin file is encrypted with International Data Encryption Algorithm, a public symmetric encryption standard. However the key is itself present inside the JAR as an XOR obfuscated string.
    The decrypted form of resource/resources.bin is a custom key value format which Codex could not identify the source of for the life in it. The JAR contains a decoder for it in its code.
    There are different alternative filenames for this file all with the same format, each one with a single key used across all JARs, and each JAR having at most one of them:
    • Applet.properties: key: 7A5DAEC4029C91ED, occurances: 76. Exmaple: aryannews.net/20101229122727/headlines.jar path c/b/b/Applet.properties.
    • Client.properties: key: 60A514D96C19F93C, occurances: 33. Example: activegaminginfo.com/20110202130304/gaming.jar path a/b/f/Client.properties
    • resource/resources.bin: key: 0C5C45F2EC3C2A63, occurances: 45. Example: all-sport-headlines.com/20110207144821/birdie.jar path resource/resources.bin
    The remaining JARs use other arrangements:
    • applet.configs, XOR-obfuscated as a single string: 35. Example: aeronet-news.com/20110202122601/aeronet.jar path a/a/b/applet.configs. Deobfuscated content might look like:
      #Applet Properties
#Thu Aug 19 08:19:00 AMT 2010
RequestKey.UserData.1.IsQuery=set
Applet.BundleSize=1
ResponseKey.UserData.0.Size=85
    • bw.properties, ZIP-packed: 30. Example: casanewsnow.com/20110201184918/casanews.jar path b/a/bw.properties
    • none of these configuration resources: 9. Example: factorforcenews.com/20110202125321/factorspeed.jar
    These files contain a wide variety of resources, including server paths, images, user strings and various settings.
  • there's a certain number of timestamps present in the Jars. Although these could have been faked, it feels unlikey that they were. The sources of those include:
    • ZIP modification time of each file
      • present in: all JAR, since JARs are ZIPs
      • timezone: no
      • visible with: zipinfo -v travelxtreme.net/20101226193020/xtreme.jar
    • Certificate validity dates:
      • present in 37 JARs. Example: latinamericanewsbeat.com/20100513191045/today.jar file META-INF/INLINE.DSA
      • timezone: yes
      • format: Standard binary PKCS#7/X.509 encoding unencrypted, readable with OpenSSL
      • usage: these are part of a standard JAR public key signatures scheme, which if a key trusted would have given greater execution priviledges to the JAR. They are validly signed but self signed as you might expect...
    • applet.configs: comment timestamp as shown above
    • Starbuck client comment as shown above:
      #Auto-generated Starbuck client config file: Mon Jun 21 14:32:02 ACT 2010
    • config key backup Unix epoch milliseconds key, e.g. the 1277148810409 in Config.properties.old.1277148810409. So their editing tool kept backups as they were editing it, which is a small OPSEC defect.
Many of the timestamps present are much older than the earliest archive we have for each website, suggesting that they were around for much longer. E.g. 2005-06-02.
The operators worked exclusively on weekdays, and much less on Friday than other days of the week, lol they're only human:
   Day          Configuration timestamps    Distinct configuration calendar dates    ZIP timestamps¹
   Monday                             21                                       11                 72
   Tuesday                            12                                       10                 78
   Wednesday                          16                                       13                 72
   Thursday                           12                                       11                 72
   Friday                              5                                        5                 60
   Saturday                            0                                        0                  0
   Sunday                              0                                        0                  0
92% of timestamps fall in conventional work hours between 08:00 and 18:00, so it was not a James Bond work through the clock to save the world business.
The timezones are:
Timezone label    applet.configs    Backups in resources.bin    Total    Possible locations / interpretations
  EST                          9                           4       13    Eastern United States, eastern Canada, parts of the Caribbean
  EDT                          8                          11       19    Eastern United States, eastern Canada, parts of the Caribbean
  AMT                         18                           0       18    Western Brazil (Amazon Time), Armenia
  ACT                          0                          16       16    Acre in Brazil (Acre Time), Northern Territory in Australia if interpreted as Java’s short timezone ID
EST an EDT are obvious, Langley. ACT is understandable, Australia, a Five Eyes country and center of US espionage is East Asia. But AMT? That one is weird.
A few sites have timestamps from multiple locations e.g.:
Site                               Labels and counts
internationalnewsworthiness.com    EDT ×2, ACT ×2
intlnewsdaily.com                  EDT ×2, ACT ×1
www.myhealthlibrary.net            EDT ×1, ACT ×5
www.todaysnewsreports.net          EDT ×1, ACT ×3
Codex also spots the interesting case of myhealthlibrary on April 11, 2011 backup sequence, configuration comments go:
09:18:19 ACT
13:59:13 EDT
13:34:14 ACT
13:43:20 ACT
14:17:18 ACT
which in UTC would jump backwards in time if ACT actually means Australia...
09:18:19 ACT    April 10, 23:48:19
13:59:13 EDT    April 11, 17:59:13
13:34:14 ACT    April 11, 04:04:14
13:43:20 ACT    April 11, 04:13:20
14:17:18 ACT    April 11, 04:47:18
but would work neatly if ACT is actualy Acre Standard time at UTC-4. Damn, Brazilian operators???
14:18:19 UTC
17:59:13 UTC
18:34:14 UTC
18:43:20 UTC
19:17:18 UTC
Codex also comments:
One historical wrinkle: Acre’s official clocks used UTC−4 during 2008–2013, including April 2011. An older Java timezone database could still apply UTC−5, so the label alone doesn’t establish the offset actually used.
Too strong. Too strong.
About the backups Codex analyses:
  • 31 backups across 11 sites; eight sites have multiple backups.
  • Of 20 successive intervals, 11 are under an hour, 15 under a day.
  • Four intervals exceed a month; the longest is about 560 days.
This fits bursts of configuration work followed by occasional maintenance.
The most advanced reverse engineering effort prior to Codex had been by GitHub user quat1024, an undergratuate student at Ohio State University, Minecraft modding extraordinaire and furry afficionado. Minecraft is written in Java, which may partly explains his Java skills.
He managed to deobfuscate the strings present inthe JARs using Enigma, possibly github.com/FabricMC/Enigma, a Java reverse engineering tool. Cool findings on web.archive.org/web/20110208072027/http://newsupdatesite.com/update.jar include:
  • applet.configs1 deobfuscated contains a date:
     Fri Feb 05 12:04:29 EST 2010
    Also cool is the present of a timeszone, "EST" unsurprisingly.
.
./c
./c/b
./c/b/b.class
./c/b/c.class
./c/b/d.class
./c/b/a
./c/b/a/a.class
./c/b/a/b.class
./c/b/a/c.class
./c/b/a/d.class
./c/a
./c/a/a.class
./c/a/b.class
./c/a/c.class
./b
./b/a
./b/a/a
./b/a/a/e.class
./b/a/a/f.class
./b/a/a/a.class
./b/a/a/b.class
./b/a/a/g.class
./b/a/a/c.class
./b/a/a/d.class
./META-INF
./META-INF/MANIFEST.MF
./a
./a/cre
./a/a
./a/a/b
./a/a/b/a.class
./a/a/a
./a/a/a/e.class
./a/a/a/applet.configs
./a/a/a/b
./a/a/a/b/e.class
./a/a/a/b/f.class
./a/a/a/b/b.class
./a/a/a/b/g.class
./a/a/a/b/c.class
./a/a/a/b/d.class
./a/a/a/b/a
./a/a/a/b/a/a.class
./a/a/a/b/a/b.class
./a/a/a/b/a/c.class
./a/a/a/c.class
./a/a/a/d.class
./a/a/a/a
./a/a/a/a/a.class
so it is fully obfuscated.
./META-INF/MANIFEST.MF
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.1
Created-By: 1.5.0_17-b04 (Sun Microsystems Inc.)
Other files whose existence might help to fingerprint include:
  • a/a/a/applet.configs
  • empty a/cre
A quick:
find . -type f | xargs strings | sort -u
does not reveal any obvious cryptography calls.
web.archive.org/web/20110207204640/http://flyingtimeline.com/aircraft.jar is very similar looking. META-INF/MANIFEST.MF is identical:
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.1
Created-By: 1.5.0_17-b04 (Sun Microsystems Inc.)
web.archive.org/web/20110202185659/http://differentviewtoday.com/bwm.jar is a bit different with tree:
META-INF/MANIFEST.MF
a/a.class
b/a/a/a.class
b/a/a/b.class
b/a/a/c.class
b/a/b/a.class
b/a/b/b.class
b/a/b/c.class
b/a/b/d.class
b/a/b/e.class
b/a/bw.properties
b/a/c.class
c/a/a/a.class
c/a/a/b.class
c/a/a/c.class
c/a/a/d.class
c/a/b.class
c/a/c.class
c/a/d.class
c/a/e.class
c/b/a.class
c/b/b.class
c/b/c.class
and:
META-INF/MANIFEST.MF
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.6.5
Created-By: 1.5.0_12-b04 (Sun Microsystems Inc.)
There are two types of JavaScript found so far. The ones with SHA and the ones without. There are only 2 examples of JS with SHA:
Both files start with precisely the same string:
var ms="\u062F\u0631\u064A\u0627\u0641\u062A\u06CC",lc="\u062A\u0647\u064A\u0647 \u0645\u062A\u0646",mn="\u0628\u0631\u062F\u0627\u0632\u0634 \u062F\u0631 \u062C\u0631\u064A\u0627\u0646 \u0627\u0633\u062A...\u0644\u0637\u0641\u0627 \u0635\u0628\u0631 \u0643\u0646\u064A\u062F",lt="\u062A\u0647\u064A\u0647 \u0645\u062A\u0646",ne="\u067E\u0627\u0633\u062E",kf="\u062E\u0631\u0648\u062C",mb="\u062D\u0630\u0641",mv="\u062F\u0631\u064A\u0627\u0641\u062A\u06CC",nt="\u0627\u0631\u0633\u0627\u0644",ig="\u062B\u0628\u062A \u063A\u0644\u0637. \u062C\u0647\u062A \u062A\u062C\u062F\u064A\u062F \u062B\u0628\u062A \u0635\u0641\u062D\u0647 \u0631\u0627 \u0628\u0627\u0632\u0622\u0648\u0631\u06CC \u06A9\u0646\u064A\u062F",hs="\u063A\u064A\u0631 \u0642\u0627\u0628\u0644 \u0627\u062C\u0631\u0627. \u062E\u0637\u0627 \u062F\u0631 \u0627\u062A\u0651\u0635\u0627\u0644",ji="\u063A\u064A\u0631 \u0642\u0627\u0628\u0644 \u0627\u062C\u0631\u0627. \u062E\u0637\u0627 \u062F\u0631 \u0627\u062A\u0651\u0635\u0627\u0644",ie="\u063A\u064A\u0631 \u0642\u0627\u0628\u0644 \u0627\u062C\u0631\u0627. \u062E\u0637\u0627 \u062F\u0631 \u0627\u062A\u0651\u0635\u0627\u0644",gc="\u0633\u0648\u0627\u0631 \u06A9\u0631\u062F\u0646 \u062A\u06A9\u0645\u064A\u0644 \u0634\u062F",gz="\u0645\u0637\u0645\u0626\u0646\u064A\u062F \u06A9\u0647 \u0645\u064A\u062E\u0648\u0627\u0647\u064A\u062F \u067E\u064A\u0627\u0645 \u0631\u0627 \u062D\u0630\u0641 \u06A9\u0646\u064A\u062F\u061F"
Good fingerprint present in all of them:
throw new Error("B64 D.1");};if(at[1]==-1){throw new Error("B64 D.2");};if(at[2]==-1){if(f<ay.length){throw new Error("B64 D.3");};dg=2;}else if(at[3]==-1){if(f<ay.length){throw new Error("B64 D.4")
Notably, the password is hardcoded and its hash is stored in the JavaScript itself. The result is then submitted back via a POST request to /cgi-bin/goal.cgi.
TODO: how is the SHA calculated? Appears to be manual.
The JavaScript of each website appears to be quite small and similarly sized. They are all minimized, but have reordered things around a bit.
First we have to know that the Wayback Machine adds some stuff before and after the original code. The actual code there starts at:
ap={fg:['MSXML2.XMLHTTP
and ends in:
ck++;};return fu;};
We can use a JavaScript beautifier such as beautifier.io/ to be abe to better read the code.
It is worth noting that there's a lot of <script> tags inline as well, which seem to matter.
Further analysis would be needed.
Codex did some SWF reverse engineering for us creating the analysis script: jar.py and should be pointed to a dump directory of the websites such as CIA 2010 websites dump. The analysis below was done as of commit b9eb31618c36421133e4875bc1cd7d7ac7763a32.
Unfortunately, the SWF are much less interesting than the JAR files.
According to Codex' analysis, it is just a lean client, and doesn't even contain its own UI which seems to be downloaded from the server. As such, we will never know what it actually looked like.
One thing that they do do is to load a gallery or things that it loops through, presumably images, and loop through them automatically. These are loaded one by one from the server, and it keeps doing server requests after that.
Codex mentions that the SWF could also download another SWF to execute, which could in turn contain the login UI, possibly upon click. But it is all hidden.
A particularly interesting example is worlddispatch.net/servlet/news2. This is apparently a helper page for the SWF, but perhaps because the website became broken after it was abandoned, it was archived, and contains the following 10 bytes of a URL query string:
c=0&f=3424
Codex' reverse engineering identified what the parameters do exactly:
  • c=0: Selects the ordinary content-cycling mode. c=1 selects a different scrolling/animated branch.
  • f=3424: advance to the next content item every 3.424 seconds, when content is available. The code's default is 4 seconds.

Ancestors (13)

  1. Methodology
  2. CIA 2010 covert communication websites
  3. Central Intelligence Agency
  4. American intelligence agency
  5. United States Intelligence Community
  6. Intelligence community
  7. Secret service
  8. Espionage
  9. War
  10. Social science
  11. Scientific method
  12. Science
  13. Home

Incoming links (2)

View article source

Discussion (0) New discussion

There are no discussions about this article yet.

Articles by others on the same topic (0)

There are currently no matching articles.
See all articles in the same topic Create my own version