xorl %eax, %eax

Archive for the ‘opsec’ Category

OPSEC fail: China and the African Union center

leave a comment »

It is becoming more and more common seeing big players doing childish operational security mistakes and this is one of them. The entire failure can be summarized effectively by the following picture. But looks like some people have still a lot to learn…

The story is relatively simple and straightforward. Around 5 years ago China donated the headquarters building, including all the infrastructure and technical support, of the organization in Addis Ababa. African Union happily started using it as it was a generous diplomatic relationship act. But 5 years later, in January 2018 it was discovered that the servers of the building were backdoored.

Specifically, they noticed that every night at around 02:00 there was a lot of traffic originating from the African Union’s HQ with the destination being some unidentified servers in Shanghai, China. The story was brought to light by Le Monde on 26 January 2018.

So, the lesson here is simple. There is so such thing as free lunch. No matter who you are or what you do, no one will give you something for no reason. Especially when it comes to technology. If you are in a decision making position keep this in mind (if you didn’t already), trust no one.

Written by xorl

February 5, 2018 at 19:37

Posted in opsec

OPSEC fail: Triton ICS malware

leave a comment »

This was a pretty nasty OPSEC failure that happened about two months ago. And it all started with one of my favourite threat hunting platforms, VirusTotal. Basically, the failure is nothing more than this, someone uploaded this targeted malware on VirusTotal and this is how it got leaked. So, this post will not focus that much on the malware but on its OPSEC failure side.

The above photo includes some of the products of SIS (Safety Instrumented Systems). SIS’ ICS devices is the target of this, now public, malware which is known as Triton or Trisis. If you want to fully understand what this malware does I suggest you to study the following.

What is important for this post is the operational security side of things. Like many others, I personally use online sandbox services like VirusTotal for threat hunting but not only for new malware samples, but also for non-malicious documents that include sensitive information. This is a common technique but many professionals tend to forget it. So, what can you do about it?

A few easy steps that you can employ to protect your organization are the following.

  • During the interview process (or awareness training) assess the OPSEC understanding of your employees. For example, if someone describes an analysis using some online or cloud tool ask “what is the risk of using this tool for the analysis?”. Basically, make them think twice before submitting anything outside the organization’s network.
  • Use endpoint solutions and perimeter application level firewalls to allow access to sharing platforms only to employees that need it for their work. This will limit the potentially unintended leaks.
  • For the day-to-day detection operations, deploy scrapers that will be hunting for your IP (Intellectual Property) on online sharing platforms. Check for example Huginn.
  • To effectively respond to those incidents, watermark your high value information so that they can be traced back easily.

Triton/Trisis was a valuable piece of code that some organization lost due to bad OPSEC. Don’t make the same mistakes. :)

Written by xorl

February 4, 2018 at 11:58

Posted in opsec

OPSEC fail: Hawaii Emergency Management Agency

leave a comment »

The past few days Hawaii Emergency Management Agency became popular in the news due to a false emergency alert which was a result of human error along with badly designed UI. This media attention brought to light some bad OPSEC practices from this agency.

News agencies start digging for content for the Hawaii Emergency Management Agency and brought up a news article from 22 July 2017 titled “North Korea Missile Threat ‘Unlikely,’ But Hawaii Prepares”. This news article from Associated Press included some high resolution photos. One of them was the following which shows Jeffrey Wong, the Hawaii Emergency Management Agency’s current operations officer and it was taken at the agency’s headquarters in Honolulu on 21 July 2017.

The photo reveals various details about the agency including the software used, internal discussion board, naming conventions, etc. However, the following close up gives some really interesting insights.

On the far right in the above photo we have a paper with the SWP (State Warning Points) call list that includes phone numbers per region. Then each of the two monitors has a Post-It note. The right one (WP2) says “Sign out” and the left one (WP1) says “Password Warningpoint2”. So, multiple operational security failures in this agency as well as the AP photographers and journalists that did not censor all those sensitive details from the photos before publishing them.

Written by xorl

January 17, 2018 at 10:10

Posted in opsec

OPSEC fail: HiddenWallet

leave a comment »

This was another issue reported by x0rz in early November 2017. The HiddenWallet is a darweb wallet service for Bitcoin that not only manages the keys but it mixes the Bitcoins to make tracing harder and says that it designed to help in Bitcoin laundering, washing and/or mixing. Meaning quite shady, and potentially illegal activities are involved.

Probably the best highlight of this Tor hidden service is what I have highlighted below. A mention of how offering those services over “clearweb” is a really bad practice if you try to remain anonymous.

However, this is exactly what this service does. A simple lookup for its domain name (nql7pv7k32nnqor2[.]onion) in Shodan reveals that the administrator of this website offers all content from clearnet too. You can see the real IP address and details that Shodan discovered here.

As we can see from Shodan, the server is configured to run two instances of Apache httpd. The one in port 8081 hosts the HiddenWallet Tor hidden service, and the one in port 80 is just an empty directory from Apache’s directory listing.

If we check for Apache Server Status page we will be quite impressed because it is actually there and leaking tons of sensitive information about the system. This includes the real hostname of the server (criminal[.]cyberbunker[.]nl) and a new listening port (8082) that has the same empty directory listing as 8081. Below is the output of the server status page with censored fields on numbers that can be used to trace back my request.

A quick research on the hosting provider (Zyztm Research Division 10 B.V.) reveals that it is a known cyber-crime hosting service based in the Netherlands that hosts all sorts of illegal services including malware Command & Control servers, illegal markets, etc. Below is the WHOIS data for this provider.

organisation: ORG-ZR3-RIPE
org-name: ZYZTM Research Division #10 B.V.
org-type: OTHER
address: Apeldoornseweg 53
address: NL-8172 EH
address: Vaassen
address: The Netherlands
e-mail: hostmaster@zyztm.com
mnt-ref: ZYZTM-MNT
mnt-by: ZYZTM-MNT
source: RIPE # Filtered

person: Ing H.J. Xennt
address: ZYZTM Research #10 B.V.
address: Apeldoornseweg 53
address: NL-8172 EH
address: Vaassen
address: The Netherlands
mnt-by: ZYZTM-MNT
e-mail: xennt@zyztm.com
phone: +31 113 323330
nic-hdl: ZYXE1-RIPE
source: RIPE # Filtered

Furthermore, the hostname of the server indicates a potential relationship with the well known CyberBunker. A lookup on the AS number shows that this IP range is registered to ZYZTM hosting provider since 2013.

Country          :  NL
Registration Date:  2013-09-18
Registrar        :  ripencc
Owner            :  ZYZTM, NL

The long operation of this ISP is also visible via SpamHaus that has a brief overview of how this provider has been observed hosting professional spammers, stolen credit cards, and other botnet & malware activity. You can read the report here.

Going back to the HiddenWallet IP address, we can see that RiskIQ Community edition has tagged it with “blacklist” and “phising” and it is live since 17 November 2016.

Using OnionScan we can see that the website is configured on WordPress but nothing else that we haven’t discovered already. More research reveals a PDF document from Recorded Future from 11 October 2017 titled “Proliferation of Mining Malware Signals: A Shift in Cybercriminal Operations” which includes the HiddenWallet’s IP address in the list of IOCs (Indicators of Compromise). Specifically, it includes the 8081/tcp service as the IP of a server with potential cryptocurrency mining malware. This could explain what was running there in the past.

Another interesting discovery was a Google result from a website (nodgitiy[.]me) that had a file (rce.txt) which included a command that sets up a connect-back shell to the IP address of the HiddenWallet server on port 1337/tcp. This was almost certainly part of an exploit code or backdoor but neither the website, nor the cached version are available to verify it.

Additionally, from this open-sources collection I discovered a forum user (handle “can”) who was using the same IP address to share some content with other forum members. The post is from 9 December 2016 which is after HiddenWallet had started (November 2016) meaning that this user is either affiliated or is the owner of this specific server.

The forum user “can” has been a member since 15 December 2009 and seems to be very active. I am not going to do a full investigation here but the above are enough information to start forming some action points for an investigation. It is an interesting case of a threat actor that is probably involved with other forms of cyber-crime for years, beyond the Bitcoin laundering service that initiated this.

Written by xorl

November 23, 2017 at 22:20

Posted in opsec

OPSEC fail: Reality Winner & The Intercept

leave a comment »

I always advice everyone to never trust journalists but this case took it to whole new level. This was a double OPSEC failure by both NSA contractor Reality Winner and the popular online news website The Intercept. Most people probably remember the case as it was very recent (June-July 2017) but it is still worth to document it for future reference.

On 5 June 2017 The Intercept published the “Top-Secret NSA Report Details Russian Hacking Effort Days Before 2016 Election”. I will avoid any political comments (as this appears to be intention of that article) and go directly to the issue. The article included a five pages long scanned PDF document that neither the whistleblower, nor The Intercept bothered to sanitize. You can find it here.

The TOP SECRET NSA report included a very nicely structured link-analysis diagram (see below) which shows that that an email address relating to a targeted phising attack was registered with a personal cell phone number which allegedly belonged to a GRU employee. This email address was also used to send the first phising email (probably testing) to the personal email account of the same GRU employee. This resulted in the attribution of this cyber-attack attempt to the Russian government. Now let’s move back to the OPSEC failure.

As you probably already know, since mid-80s all printers have digital watermarks (most commonly known as “yellow dots”). Those are some tiny yellow dots with a standard encoding, which are unique to each printer and are being included in all documents printed. Their official name is Machine Identification Code (MIC) and you can find more about it on Wikipedia and EFF.

So, long story short, neither The Intercept nor the whistleblower performed a basic sanitization of the stolen document. The whistleblower printed it on printer belonging to an NSA office, and sent it to The Intercept. You can easily find this on your own. Download the document, zoom in (500%-600% is sufficient), load this to your favorite image editing software, change the color hue & saturation, and there you have it.

Using EFF’s decoder you can find some details around it. However, you will quickly notice that you need to rotate (180 degrees) the MIC to properly decode it. You can see the result here. Basically, it is the printer’s serial number (535218 or 29535218), and date & time it was printed (9 May 2017 06:20). More than enough information for an intelligence agency to locate the whistleblower.

And this is exactly what happened there. Literally the next day after the news article was published, on 6 June 2017, the FBI arrested Reality Winner who was working as NSA contractor at that time. The trail that resulted to her arrest as FBI explained was the printer’s digital watermark along by NSA’s office printers’ logging. Basically, they knew the printer it came from, the date & time so the only thing left was to check the logs to see who used it at that time. That simple.

This was a major OPSEC failure. A technology that is known since the 80s was completely ignored by both an NSA contractor and a popular news agency. On the other hand, it is worth noting that this case must act as an important lesson for all businesses as many of them do not keep an inventory of the MICs of their printers. Something which can be used to detect insider threats as this case demonstrated in the best possible way. Maybe something you can keep in mind if you haven’t done it already.

Written by xorl

November 21, 2017 at 21:25

Posted in opsec

OPSEC fail: GearBank International

leave a comment »

In this post we will explore a case of an operational security mistake reported by x0rz in September. This one is for an illegal performance enhancing drugs darkweb site called GearBank International (abbreviated as GBI). Okay, so let’s see how you can discover the real address and details of this cyber-crime website.

Following the same technique and using Censys.io as described in “OPSEC fail: TanieRC”, when looking for gearbankbaesqqv7[.]onion you discover that the web server was accessible from clearnet too, leaking the real IP address of the server.

Below you can see the information that we learned from this operational security failure. That information can be very valuable for law enforcement agencies working on cyber-crime.

IP address      :
Hostname        : testgb
Onion address   : gearbankbaesqqv7.onion
Hosting provider: Omnilance Ukraine
Web server      : Apache 2.2.22
Email address   : gearbankintl@tutanota.com

By pivoting on the contact email address we can collect even more information on this cyber-criminal. Using basic OSINT methodologies, we quickly identified that the same email address has been used in the following domains which were pointing to the same illegal website (this time hosted in Cloudflare).

  • gearbankintl[.]cc
  • gearbankintl[.]pw

In addition, a second email address was used in there, it was the gearbakintl@countermail.com. Pivoting with that email did not reveal any other domains or information. Moving to RiskIQ community edition platform, we can see that the earliest date for those domains is 15 November 2015. The most notable discovery however was the historical data on WHOIS for that domain. Since the very beginning it was registered by Dimitry Pshyck using gbi@tuta.io email address.

By pivoting on the email address that was used for the registration of those domains, we can see that it was also used to register saizin[.]cc in July 2016. You can see this below.

This website was also used for selling illegal performance enhancing drugs. Although the website is no longer live, using Archive.org we can find a snapshot from 17 November 2016. It doesn’t include most of the content but we can see some interesting details such as that it was using OpenCart, and it was affiliated with Eroids and MuscleGurus websites. Exactly like GBI.

Looking for the name, phone, and address did not result in any notable discovery. However, from this very basic OSINT collection, we were able to associate all of the following data with a cyber-criminal that has been selling illegal performance enhancing drugs since 2015.

IP address      :
Hostname        : testgb
Onion address   : gearbankbaesqqv7.onion
Hosting provider: Omnilance Ukraine

Email address   : gearbankintl@tutanota.com
Email address   : gearbakintl@countermail.com
Email address   : gbi@tuta.io
DNS name        : gearbankintl.cc
DNS name        : gearbankintl.pw
DNS name        : saizin.cc
Name            : Dimitry Pshyck
Phone number    : +380.957026548
Address         : 7 Kryshatic #30 Kiev 010020 Ukraine

Written by xorl

November 16, 2017 at 23:32

Posted in opsec

OPSEC fail: TanieRC

with 2 comments

So, a few hours ago I noticed that Sh1ttyKids mentioned the OPSEC fail of a darkweb illegal drug dealer, the TanieRC. So, I decided to make a more detailed post about it in order to help more people discover and report those cyber-crime websites to the authorities. So, let’s see what’s TanieRC…

TanieRC is a Polish illegal drug dealer that started in 20 October 2017. Here is where the OPSEC of this threat actor failed, using Censys.io you can search for the contents of an indexed website. In this case, searching for IPv4 entries that include “taniercil76mgjl3.onion” which is part of the website as you can see in the HTML code of the page, reveals the real IP address of this Tor hidden service. A big fail in the server configuration as the whole purpose of a Tor hidden service is to hide the actual servers that are serving the content.

This is clearly an operational security fail on the cyber-criminal side. Below is a quick list what we learned from this OPSEC failure in this particular case.

IP address        :
Hostname          : ip90.ip-193-70-95.eu
Onion address     : taniercil76mgjl3.onion
Web server        : nginx 1.2.1
SSH daemon        : OpenSSH 6.0p1
Operating System  : Debian-4+deb7u2 
SSH fingerpint    : e2890700ba42d5baf545a61afe1427fe24a0472bfafe79d6b8563e3ba6caf95d
Available services: HTTP, SSH, FTP

Starting with a WHOIS it is clear that this server is not hosted directly to the French OVH, but instead it is from a small Polish hosting provider called IQ-Group that registered this range in 11 September 2017. The IQ-Group itself was registered in RIPE in 06 July 2017.

inetnum: -
netname:        OVH_151685543
country:        PL
descr:          Failover Ips
org:            ORG-IA1520-RIPE
admin-c:        OTC12-RIPE
tech-c:         OTC12-RIPE
status:         ASSIGNED PA
mnt-by:         OVH-MNT
created:        2017-09-11T15:33:27Z
last-modified:  2017-09-11T15:33:27Z
source:         RIPE

organisation:   ORG-IA1520-RIPE
org-name:       Adam Buhl IQgroup
org-type:       OTHER
address:        10 Sudeckiej Dywizji Zmechanizowanej 4
address:        45-828 Opole
address:        PL
e-mail:         abuhl@iq-group.pl
phone:          +48.609651027
abuse-c:        ACRO9280-RIPE
mnt-ref:        OVH-MNT
mnt-by:         OVH-MNT
created:        2017-07-06T08:16:12Z
last-modified:  2017-10-30T14:49:52Z
source:         RIPE

Since this is tiny IP range, we can easily scan it to see if there are any other illegal websites hosted there. The result is the following. - not used - not used - not used - not used - not used - Apache2 Ubuntu Default Page, Postfix, & SSH - Apache2 Ubuntu Default Page, Postfix, & SSH - Apache2 Ubuntu Default Page, Postfix, & SSH - Apache2 Ubuntu Default Page, Postfix, & SSH - PHP info page, Postfix, & SSH - TanieRC (drug dealer) - webkillerr.xaa.pl - Apache2 Ubuntu Default Page, Postfix, & SSH - GGspeak.pl - not used - not used

This suspicious hosting provider also points to an address (10 Sudeckiej Dywizji Zmechanizowanej 4, 45-828 Opole) which leads to some industrial area of warehouses. Kind of an an unusual place for a small hosting company. Here is a photo from Google Street View for the specified address.

Again, none of those directly relate the hosting provider company with the drug dealer, but it is definitely a relationship that needs some further investigation. In the future I will post more of those quick investigations from failed OPSEC of illegal websites. Hope that you liked it. :)

Written by xorl

November 11, 2017 at 22:54

Posted in opsec