April 20 2018 | by Korvin AG |
Whatever system you are
using, if it is having some sort of data input interface, an
external power supply and potentially a connection to the
net - it can be hacked. Period.
What I describe here is a simple method to circumvent most protective means, let these be software or hardware-based ones. It needs no code to run on the system and consequently there is no defense against it (alas, there is one - but read on! :) ). Mostly used on the x86 architect, but it has derivatives on all widespread systems.
It is no other than
tinkered keyboards and/or mouses. Once these are connected
to a system they act like normal peripherals (for example by
identifying itself as an Intellimouse (0x03)
upon the GetDeviceID (0xF2) command), only these are having
some extras. The extras are some custom algorithms, which
are directing the collection efforts that these devices are
designed to be capable of.
There are two families
of these that I know of, the first family is called
'Impetus', which is now a perhaps discontinued line. These
were using the serial PS/2 (6-pin mini-DIN) connector and
there were pointer devices and keyboards of this line, used
together in most cases. These were built into legit
The collection of data
with the 'Impetus' devices is rather crude. It is done by
recording a set of commands sent by the device to the host
controller over a longer period, calculating the necessary
commands to be sent when the pointer (in the case of a
mouse) is in the initial position (this is when after the
power-up there is no user input for a set number of clock
cycles) to open programs via moving the pointer and clicking
on the desktop icons, then highlight text, copy it, opening
the email client, sending the text, etc. Of course the
actions are visible to anyone in front of the screen, but as
it is done using the default 'Set Sample Rate' (e.g. 100
samples/second) at the default 'Set Resolution' value (a
resolution of 4 counts/millimeters), the predetermined
pointer movements are seen as a sole momentary vibration.
These actions are
directed by an extended EPROM. The 'Impetus' was developed
over the PS/2 protocol mainly because it is the same
protocol that had been used by the so-called 'AT keyboards'
as well - so the 'Impetus' was able to control the most
important input vectors once these were physically connected
to a system. In the case of the mouse, it used the 'Reset'
(0xFF) command received on start-up to enter its own
collection mode rather than to run the Basic Assurance Test
that would have been the norm. 'Impetus' is able to count
clock cycles after the host controller sends the 'Enable
Data Reporting' (0xF4) command in the stream mode, thus it
can guess after a set number of clock cycles (that the mouse
generates and not the host controller)that the user is not
around the computer. Also it has some sniffing capabilities
by recording and evaluating wrap mode echoes - and by
recording all counters instead of resetting. Later versions
of the 'Impetus' mice and keyboards have a built-in
emulation capability of the start-up communication between
the host and the peripherals, which needs something like 25
command & report line pairs.
The 'Impetus' keyboards
were using the same PS/2 protocol, but these were actually
either keystroke recorders (using an extra built-in power
supply and a memory capable of holding the last n
keystrokes) or the necessary means to help out a broader
action by reporting given keystrokes once a given sequence
of commands are arriving from the host controller (like 4 in
a row of 'Resend' (0xFE) or 'Set/Reset Indicators' (0xED)
followed by a specific argument byte to switch the CapsLock
LED for example).
The 'Impetus' devices
were manufactured somewhere in Europe, starting in 1990, by
some suddenly jobless experts. Very soon, however they found
their way back in to state organizations. The first models
were created in a high school lab, but later on the
manufacturing moved to a clandestine site. A few hundred of
these might be completed in at least a dozen variations but
I have no information regarding their possible uses.
According to someone involved in making these the project
was abandoned with the wide scale availability of the USB
peripherals in the early 2000s.
Errr, the project wasn't
actually abandoned, but was replaced by a newer one aimed at
fooling systems by tinkering with USB peripherals. So, the modus
operandi remained, only the tools changed.
This new family of
tinkered hardware is called 'Harpoon' - because of the
resemblance of the USB trident logo to a harpoon. The
'Harpoon' family is still developing and is based on the
many possibilities the Universal Serial Bus standards
represent. The first steps were to created devices that are
able to report multiple Device Descriptor values and could
act accordingly. In other words it could now be externally a
mouse, a keyboard, a flash memory stick, or both in a
Bluetooth package, a webcam or whatnot. Anything that has a
USB connector, that is. Their initial capabilities included
the ability to measure window sizes, locate interaction
fields (using mouse events), creatively using the
possibilities of text storage on the clipboard, the use of
power supply modes for sniffing purposes, etc. but now it
evolved into a huge system encompassing custom zero
day-driven codes, stolen or generated certificates,
botnets to liaise between the controllers and the target
systems, etc. Since it is a method that is being used one
can't tell what are the capabilities of the latest models.
But it ain't necessary to know that. They all still
masquerade themselves as either mouses or keyboards during
the POST period after power on, or after being hotplugged
into a system already running its OS.
Starting from the 1960s
a race started to gather intelligence trough recording
keystrokes at places where some secretive was typed. The
early attempts already bore fruit - just remember that the
Soviets successfully used such hardware against US diplomats
already in the 1970s, by physically installing devices
fed by the own electric supply of the Selectric II & III
electric typewriters. These bugs transmitted the logged data
over to a transmitter located a few hundred meters away.
In the 1990s and the
2000s, most endeavors in this field were directed towards
developing software solutions. These solutions were
constantly evolved for example to be able to:
be resident in the memory at all times,
log key presses from within all sessions and applications,
be invisible to the task and file managers,
be undetectable by the emerging anti-virus and firewall methods,
be able to do more: like saving printscreens, mic recordings, etc.
- identifying faulty codes,
- understanding the vulnerability,
- building an exploit,
- selecting or making a payload,
- targeting the desired target,
- finding it,
- naming it,
- publishing it,
- forcing vendors to patch the vulnerability,
- and having the story shredded in the past as newer vulnerabilities emerge.
But some techniques were never
intended to follow these guidelines. And these techniques
are the custom-built tools that are targeting specific
persons or institutions.
I promised to tell you what protection
there is against these threat classes / vectors. It is
called behavioral analysis. And with the advent of
use-able AI-driven security applications it is more than
possible to identify and neutralize new and old but
And: What you have to bear in mind is that actual hacking is not doing something that everyone does, actual hacking is doing something that no one does.
Thanks for reading and please feel free to
( If You want to contact us regarding this article or for any other reason, You could do so by sending an email to firstname.lastname@example.org )