In the first part of this post there were the cars, here are the chameleons: such name is not related to the ALE Addresses but rather to the configuration of the stations. A third part will follow in case of news or updates.
The two following networks, although they exhibit different behaviors, share some aspects which lead to think to the same source/organization or at least to the same Country. As said in the first part, the purpose is only hobbystic; sensitive and confidential messages contents, if any, are anyway not published. I'm interested on the way the "boxes" travel and NOT on their content.
|fig. 2 - sequence diagram|
ABC7: alpha bravo x y this is alpha bravo charlie seven, authenticate 79
ABXY: alpha bravo charlie seven, this is alpha bravo x y, my authenticate 6843, authenticate 74
ABC7: this is alpha bravo charlie seven, my authenticate 2895
ABXY: ok send your message
A fter finishing sending the message, the net-control station asks the receiver peer to confirm the message-number then link is terminated and the next station in turn is contacted.
|fig. 3 - 188-141A 3-way handshake and Auth keys exchange|
The hostname and the e-mail client fingerprint (point 4) clearly reveal that they use a Linux system, specifically: SUSE Linux 3.1.14. Indeed, the mention of chameleons I adopted just derives from the official logo of SUSE.
The system language is the plain en-US without language/keyboard customization.
The use of Linux is per se an interesting and peculiar element of this network, but it's not the only one. The email includes one attached jpeg/image file whose name is "PRILOG 5 - PRILOG ZA SLANJE E-MAILA.jpg". This language suggest a Slavic origin (google-translator), as confirmed by the system timezone at point "3" (+0200), time-zone and especially the language restrict the candidate Countries to two: HIB and HRV. Anyway, the most surprising fact is that the e-mails I decoded have that same attached filename although it refers two images, in other words they always use the same name for the attachments (fig. 5).
|fig. 5 - two e-mails, different ricipients but same attached filename|
In the above fig. 2 we have seen that the net-control stations asks a confirm of the received message-number: this a progressive number and matches the subject of the corresponding e-mail. The message-number is initialized to a new initial value at each day and assigned to the subject of the e-mail sent to the first station in the calling list (ie: ABD1, firstname.lastname@example.org) and then is incremented by one at each step (fig. 7).
06 Oct: initial value 600
11 Oct: initial value 603
13 Oct: initial value 508
18 Oct: initial value 610
5054 net (5054 KHz)
|fig. 9 - HMTP-66 protocol|
Addresses and origin/owner of the networks
I never heard e-mail exchanges between the two nets but only e-mails sent from linux-a5kz to the other stations of AB-net and e-mails sent from linux-2o6y.site to other stations of 5054-net: this leds to think that these are the main stations of their respective networks. It's interesting to pay a look at the e-mail addresses of the two newtorks:
ALE e-mail address
As expected, the networks belong to two different e-mail domains "123" and "111": behind such choice there is surely a certain logic but unfortunately do not offer any clue for identification.
AB-net seems to use non-sense (?) alphabetical addresses (asdf, sdfg,...) while 5054-net seems to use a sort of "structured" names (lost62, dres,32, fejk8,...). It's worth noting that the AB-net addresses, if listed in the order of the calling list, exhibit a left-shift of 3 letters. According to this schema, ABH3 could have the address email@example.com (m,n,o seem to be not used).
A big help in the identification of the source is given by the examination of the collected STANAG-5066 nodes addresses:
ALE Stanag-5066 address e-mail address
ABD1 006.008.004.166 firstname.lastname@example.org
ABG6 006.008.004.165 email@example.com
ABF2 006.008.006.226 firstname.lastname@example.org
ABS5 006.008.008.215 email@example.com
ABK4 006.008.002.144 firstname.lastname@example.org
ABH3 006.008.002.055 ?
- 006.008.004.165 email@example.com (ncs)
- 006.008.003.033 firstname.lastname@example.org
- 006.008.003.036 email@example.com
- 006.008.003.037 firstname.lastname@example.org
About the assignments of the STANAG-5066 addresses, the global-regional blocks are defined by the 4 most-significant bits of the full length address (i.e., the first element w of the dotted-decimal form w.x.y.z): from fig. 11, 6.x.y.z is assigned to Europe.
Now, what european nation matches 6.8.y.z ?
The answer is in Table N-6 "National Address Schema" STANAG-5066 Edition 3 Annex N: 5066 is a NATO unclassified document that may circulated freely and is available on:
Sadly, no part of S-5066 Edition 3 can be published but the mentioned Table N-6 matches the "proposed allocations" which are visible at page 14 (here reported in fig. 12) of a very interesting pdf file freely downloadable from: http://www.hfindustry.com (note that NC3A, NATO C3 Agency, is now NCIA or NATO Communications and Information Agency).
It's worth noting that the stations dfgh.123 and aysxd.111 exhibit the same S-5066 address 006.008.004.165, i.e. the same node: as far as I know a certain S-5066 address should not be shared by two or more nodes (duplicate address) hence we face the same physical node. Looking at the "Received" headers of one e-mail sent by aysxd.111 (fig. 13) we see that the e-mail is originated (from) and received (by) the same host linux-2o6y.site: this means that the e-mail client and the S-5066 gateway application are running inside that same host. Moreover, the IP address 127.0.0.1 (which refers the sender) is the address of the localhost: this means that the host linux-2o6y.site, i.e. the 006.008.004.165 S-5066 node, is not wired to a LAN.
STANAG-5066 gateway application
The S-5066 application running in the Linux gateway nodes add the string "CROZ ESMTP/HMTP gateway" in the received-by header, most likely its "fingerprint":
It is an application that acts either as Extended SMTP server (on the LAN side) or as HMTP gateway (on the HF network side). They do not use a Stanag-5066 applications from the most "popular" manufacturers in the place:
|Isode||Icon 5066||*||*||(development, not released)|
|Rohde & Schwarz||R&S 5066||*||-||(client part in Java)|
|Thales||-||*||-||(client part in Java)|
|fig. 16 - CroS5066 schema|
CroS5066 is fully interoperable with other S-5066 systems, positive tests were made during NATO exercises Combined Endeavor 2008 (Lager Aulenbachhere, Germany and Lora Naval Base in Split, Croatia).
(to be continued)