Malware RSS Feed
Unlike conventional World Wide Web technologies, the Tor Darknet onion routing technologies give users a real chance to remain anonymous. Many users have jumped at this chance – some did so to protect themselves or out of curiosity, while others developed a false sense of impunity, and saw an opportunity to do clandestine business anonymously: selling banned goods, distributing illegal content, etc. However, further developments, such as the detention of the maker of the Silk Road site, have conclusively demonstrated that these businesses were less anonymous than most assumed.
Intelligence services have not disclosed any technical details of how they detained cybercriminals who created Tor sites to distribute illegal goods; in particular, they are not giving any clues how they identify cybercriminals who act anonymously. This may mean that the implementation of the Tor Darknet contains some vulnerabilities and/or configuration defects that make it possible to unmask any Tor user. In this research, we will present practical examples to demonstrate how Tor users may lose their anonymity and will draw conclusions from those examples.How are Tor users pinned down?
The history of the Tor Darknet has seen many attempts – theoretical and practical – to identify anonymous users. All of them can be conditionally divided into two groups: attacks on the client’s side (the browser), and attacks on the connection.Problems in Web Browsers
The leaked NSA documents tell us that intelligence services have no qualms about using exploits to Firefox, which was the basis for Tor Browser. However, as the NSA reports in its presentation, using vulnerability exploitation tools does not allow permanent surveillance over Darknet users. Exploits have a very short life cycle, so at a specific moment of time there are different versions of the browser, some containing a specific vulnerability and other not. This enables surveillance over only a very narrow spectrum of users.
The leaked NSA documents, including a review of how Tor users can be de-anonymized (Source: www.theguardian.com)
As well as these pseudo-official documents, the Tor community is also aware of other more interesting and ingenuous attacks on the client side. For instance, researchers from the Massachusetts Institute of Technology established that Flash creates a dedicated communication channel to the cybercriminal’s special server, which captures the client’s real IP address, and totally discredits the victim. However, Tor Browser’s developers reacted promptly to this problem by excluding Flash content handlers from their product.
Flash as a way to find out the victim’s real IP address (Source: http://web.mit.edu)
Another more recent method of compromising a web browser is implemented using the WebRTC DLL. This DLL is designed to arrange a video stream transmission channel supporting HTML5, and, similarly to the Flash channel described above, it used to enable the victim’s real IP address to be established. WebRTC’s so-called STUN requests are sent in plain text, thus bypassing Tor and all the ensuing consequences. However, this “shortcoming” was also promptly rectified by Tor Browser developers, so now the browser blocks WebRTC by default.Attacks on the communication channel
Unlike browser attacks, attacks on the channel between the Tor client and a server located within or outside of the Darknet seem unconvincing. So far most of the concepts were presented by researchers in laboratory conditions and no ‘in-the-field’ proofs of concept have been yet presented.
Among these theoretical works, one fundamental text deserve a special mention – it is based on analyzing traffic employing the NetFlow protocol. The authors of the research believe that the attacker side is capable of analyzing NetFlow records on routers that are direct Tor nodes or are located near them. A NetFlow record contains the following information:
- Protocol version number;
- Record number;
- Inbound and outgoing network interface;
- Time of stream head and stream end;
- Number of bytes and packets in the stream;
- Address of source and destination;
- Port of source and destination;
- IP protocol number;
- The value of Type of Service;
- All flags observed during TCP connections;
- Gatway address;
- Masks of source and destination subnets.
In practical terms all of these identify the client.
De-anonymizing a Tor client based on traffic analysis
This kind of traffic analysis-based investigation requires a huge number of points of presence within Tor, if the attacker wants to be able to de-anonymize any user at any period of time. For this reason, these studies are of no practical interest to individual researchers unless they have a huge pool of computing resources. Also for this reason, we will take a different tack, and consider more practical methods of analyzing a Tor user’s activity.Passive monitoring system
Every resident of the network can share his/her computing resources to arrange a Node server. A Node server is a nodal element in the Tor network that plays the role of an intermediary in a network client’s information traffic. In this Darknet, there several types of nodes: relay nodes and exit nodes. An exit node is an end link in traffic decryption operation, so they are an end point which may become the source of leaking interesting information.
Our task is very specific: we need to collect existing and, most importantly, relevant onion resources. We cannot solely rely on internal search engines and/or website catalogs, as these leave much to be required in terms of the relevance and completeness of contained information.
However, there is a straightforward solution to the problem of aggregation of relevant websites. To make a list of the onion resources that were recently visited by a Darknet user, one needs to track each instance of accessing them. As we know, an exit node is the end point of the path that encrypted packets follow within the Darknet, so we can freely intercept HTTP/HTTPS protocol packets at the moment when they are decrypted at the exit node. In other words, if the user uses the Darknet as an intermediary between his/her browser and a web resource located in the regular Internet, then Tor’s exit node is the location where packets travel in unencrypted format and can be intercepted.
We know that an HTTP packet may contain information about web resources, including onion resources that were visited earlier. This data is contained in the ‘Referrer’ request header, which may contain the URL address of the source of the request. In the regular Internet, this information helps web masters determine which search engine requests or sites direct users towards the web resource they manage.
In our case, it is enough to scan the dump of intercepted traffic with a regular expression containing the string ‘onion’.
There is a multitude of articles available on configuring exit nodes, so we will not spend time on how to configure an exit node, but instead point out a few details.
First of all, it is necessary to set an Exit Policy that allows traffic communication across all ports; this should be done in the configuration file torrc, located in the Tor installation catalog. This configuration is not a silver bullet but it does offer a chance of seeing something interesting at a non-trivial port.
>> ExitPolicy accept *:*
The field ‘Nickname’ in the torrc file does not have any special meaning to it, so the only recommendation in this case is not to use any conspicuous (e.g. ‘WeAreCapturingYourTraffic’) node names or those containing numbers (‘NodeNumber3′) that might suggest an entire network of such nodes.
After launching a Tor server, it is necessary to wait until it uploads its coordinates to the server of directories – this will help our node declare itself to all Darknet participants.
An exit node in operation
After we launched the exit mode and it began to pass Tor users’ traffic through itself, we need to launch a traffic packet sniffer and intercept the passing traffic. In this case, tshark acts as a sniffer, listening to interface #1 (occupied by Tor) and putting the dump into the file ‘dump.pcap':
>>tshark –i 1 –w dump.pcap
Tshark intercepts packets that pass through the exit node in unencrypted format
All the above actions must be done on as many servers as possible to collect as much information of interest as possible. It should be noted that the dump grows quite quickly, and it should be regularly collected for analysis.
Thus, once you receive a huge dump, it should be analyzed for onion resources. Skimming through the dump helps to categorize all resources visited by Tor users by content type.
It should be noted that 24 hours of uninterrupted traffic interception (on a weekday) produce up to 3GB of dump for a single node. Thus, it cannot be simply opened with Wireshark – it won’t be able to process it. To analyze the dump, it must be broken into smaller files, no larger than 200 MB (this value was determined empirically). To do so, the utility ‘editcamp’ is used alongside with Wireshark:
>> editcap – c 200000 input.pcap output.pcap
In this case, 200,000 represents the number of packets in a single file.
While analyzing a dump, the task is to search for strings containing the substring “.onion”. This very likely will find Tor’s internal resources. However, such passive monitoring does not enable us to de-anonymize a user in the full sense of the word, because the researcher can only analyze those data network packets that the users make available ‘of their own will’.Active monitoring system
To find out more about a Darknet denizen we need to provoke them into giving away some data about their environment. In other words, we need an active data collection system.
An expert at Leviathan Security discovered a multitude of exit nodes and presented a vivid example of an active monitoring system at work in the field. The nodes were different from other exit nodes in that they injected malicious code into that binary files passing through them. While the client downloaded a file from the Internet, using Tor to preserve anonymity, the malicious exit node conducted a MITM-attack and planted malicious code into the binary file being downloaded.
This incident is a good illustration of the concept of an active monitoring system; however, it is also a good illustration of its flipside: any activity at an exit node (such as traffic manipulation) is quickly and easily identified by automatic tools, and the node is promptly blacklisted by the Tor community.Let’s start over with a clean slate
- Various graphics drivers and hardware components installed on the client’s side;
- Various sets of software in the operating system and various configurations of the software environment.
The parameters of rendered images can uniquely identify a web-browser and its software and hardware environment. Based on this peculiarity, a so-called fingerprint can be created. This technique is not new – it is used, for instance, by some online advertising agencies to track users’ interests. However, not all of its methods can be implemented in Tor Browser. For example, supercookies cannot be used in Tor Browser, Flash and Java is disabled by default, font use is restricted. Some other methods display notifications that may alert the user.
Thus, our first attempts at canvas fingerprinting with the help of the getImageData()function that extracts image data, were blocked by Tor Browser:
However, some loopholes are still open at this moment, with which fingerprinting in Tor can be done without inducing notifications.By their fonts we shall know them
Tor Browser can be identified with the help of the measureText()function, which measures the width of a text rendered in canvas:
Using measureText() to measure a font size that is unique to the operating system
If the resulting font width has a unique value (it is sometimes a floating point value), then we can identify the browser, including Tor Browser. We acknowledge that in some cases the resulting font width values may be the same for different users.
It should be noted that this is not the only function that can acquire unique values. Another such function is getBoundingClientRect(),which can acquire the height and the width of the text border rectangle.
When the problem of fingerprinting users became known to the community (it is also relevant to Tor Browser users), an appropriate request was created. However, Tor Browser developers are in no haste to patch this drawback in the configuration, stating that blacklisting such functions is ineffective.
Tor developer’s official reply to the font rendering problemField trials
This approach was applied by a researcher nicknamed “KOLANICH”. Using both functions, measureText() and getBoundingClientRect(), he wrote a script, tested in locally in different browsers and obtained unique identifiers.
Using the same methodology, we arranged a test bed, aiming at fingerprinting Tor Browser in various software and hardware environments.
A fragment of a web-server’s log with a visible Tor Browser fingerprint
At this time, we are collecting the results of this script operating. To date, all the returned values are unique. We will publish a report about the results in due course.Possible practical implications
- Internal onion resources and external web sites controlled by the attackers. For example, an attacker launches a ‘doorway’, or a web page specially crafted with a specific audience in view, and fingerprints all visitors.
- Internal and external websites that are vulnerable to cross-site scripting (XSS) vulnerabilities (preferably stored XSS, but this is not essential).
Objects that could fingerprint a Tor user
The last item is especially interesting. We have scanned about 100 onion resources for web vulnerabilities (these resources were in the logs of the passive monitoring system) and filtered out ‘false positives’. Thus, we have discovered that about 30% of analyzed Darknet resources are vulnerable to cross-site scripting attacks.
The process of de-anonymizing a Tor user
Following this approach, the attacker could, in theory, find out, for instance, sites on which topics are of interest to the user with the unique fingerprint ‘c2c91d5b3c4fecd9109afe0e’, and on which sites that user logs in. As a result, the attacker knows the user’s profile on a web resource, and the user’s surfing history.In place of a conclusion
Let’s examine a couple of interesting delivery techniques from an APT active for the past several years, the Spring Dragon APT. A paper released today by our colleagues at Palo Alto Networks presented a portion of data on this crew under the label “the Lotus Blossom Operation“, likely named for the debug string present in much of the “Elise” codebase since at least 2012: “d:\lstudio\projects\lotus\…”.
The group’s capabilities are more than the much discussed CVE-2012-0158 exploits over the past few years. Instead, the group is known to have employed half day spearphish exploits, strategic web compromises, and watering holes employing fake Flash player update re-directions. The group’s spearphish toolset includes PDF exploits, Adobe Flash Player exploits, and the common CVE-2012-0158 Word exploits including those generated from the infamous “Tran Duy Linh” kit. While ongoing attacks by the Spring Dragon APT take us back to a focus on Vietnam, they appear to have rolled out a steady mix of exploits against defense subcontractors around the world and government related organizations in VN, TW, PH, and other locations over the past few years. Let’s take a quick look at a couple more examples of their intrusion capabilities that haven’t been mentioned elsewhere.
Organizations located in Myanmar and targeted by Spring Dragon have gone unmentioned. But Spring Dragon’s infiltration techniques there were not simply 0158 spearphish, they also compromised sites. In one case, they replaced specialized font installers needed to render Myanma font. You can see an image here of the “Planet Myanmar” website in late 2012 distributing such a package. All of the zip links were redirected to a poisoned installer zip file. The download name was “Zawgyi_Keyboard_L.zip”, and it dropped a “setup.exe” that contained several backdoor components, including an Elise “wincex.dll” (a42c966e26f3577534d03248551232f3, detected as Backdoor.Win32.Agent.delp). It beacons out with the typical Elise GET request “GET /%x/page_%02d%02d%02d%02d.html”, as documented in the Lotus Blossom paper.
Another APT later abused this exact site to deliver malicious VBS (CVE-2014-6332) exploits in November of 2014 with a Lurid variant payload. And that same group also served a malicious PDF exploit (CVE-2010-2883) from this site in June 2012 as “Zawgyi Unicode Keyboard.pdf”. Even earlier than that, they spearphished with that same PDF exploit object later hosted on the website under different file names. In November 2011, they used filenames appropriate for their spearphishing targets with this exploit like “台灣安保協會「亞太區域安全與台海和平」國際研討會邀 請 函_20110907.pdf” (“Taiwan Security Association International Seminar Invitation – the Asia-Pacific regional security and peace in the Taiwan Strait”), “china-central_asia.pdf”, “hydroelectric sector.pdf”, and various governmental related proposals. In this case, there was unexpected overlap from two APT.
Another interesting technique that we observed in use against government targets was a campaign that lured recipients to a site redirecting users to a spoofed Flash installer site.
This site in turn redirected users to a Flash installer bundled with the common Elise backdoor, eventually communicating with 220.127.116.11 and its usual “GET /14111121/page_321111234.html HTTP/1.0″.
hxxp://www.bkav2010.net/support/flashplayer/downloads.html → redirected to
While this particular actor effectively used their almost worn out CVE-2012-0158 exploits in the past, Spring Dragon employs more involved and creative intrusive activity as well.
We have previously described how Duqu 2.0 doesn’t have a normal “persistence” mechanism. This can lead users to conclude that flushing out the malware is as simple as rebooting all the infected machines. In reality, things are a bit more complicated.
The attackers created an unusual persistence module which they deploy on compromised networks. It serves a double function – it also supports a hidden C&C communication scheme. This organization-level persistence is achieved by a driver that is installed as a normal system service. On 64-bit systems, this implies a strict requirement for an Authenticode digital signature. We have seen two such persistence drivers deployed in the course of attacks.
During their operations the Duqu threat actors install these malicious drivers on firewalls, gateways or any other servers that have direct Internet access on one side and corporate network access on other side. By using them, they can achieve several goals at a time: access internal infrastructure from the Internet, avoid log records in corporate proxy servers and maintain a form of persistence after all.
In essence, the drivers are redirecting network streams to and from the gateway machine that runs it. To forward connections, the attacker first has to pass a network-based “knocking” mechanism by using a secret keyword. We have seen two different secret keywords in the samples we collected so far: “romanian.antihacker” and “ugly.gorilla”.
We described one of these drivers in our whitepaper about Duqu 2.0 (see “The ”portserv.sys” driver analysis” section). Let us repeat some of the most important details. The driver listens to the network and expects a special secret keyword (“romanian.antihacker” in that case). After that, it saves IP of the host that passed the correct secret keyword and starts redirecting all packets from port 443 to 445 (SMB) or 3389 (Remote Desktop) of that server. This effectively allows the attackers to tunnel SMB (i.e. remote file system access) and Remote Desktop through the gateway server while making it look like HTTPS traffic (port 443).
In addition to the “romanian.antihacker” driver, we have discovered another one which did a similar job, however, supporting more connections in a more generic way:
- If the driver recognizes the secret keyword “ugly.gorilla1” then all traffic from the attacker’s IP will be redirected from port 443 (HTTPS) to 445 (SMB)
- If the driver recognizes the secret keyword “ugly.gorilla2” then all traffic from the attacker’s IP will be redirected from port 443 (HTTPS) to 3389 (RDP)
- If the driver recognizes the secret keyword “ugly.gorilla3” then all traffic from the attacker’s IP will be redirected from port 443 (HTTPS) to 135 (RPC)
- If the driver recognizes the secret keyword “ugly.gorilla4” then all traffic from the attacker’s IP will be redirected from port 443 (HTTPS) to 139 (NETBIOS)
- If the driver recognizes the secret keyword “ugly.gorilla5” then all traffic from the attacker’s IP will be redirected from port 1723 (PPTP) to 445 (SMB)
- If the driver recognizes the secret keyword “ugly.gorilla6” then all traffic from the attacker’s IP will be redirected from port 443 (HTTPS) to 47012 (currently unknown).
We would like to note that one port here looks quite suspicious: 47012. So far, we haven’t seen any other Duqu 2.0 components using this port, nor have we found any other common malware, backdoor or legitimate software using this port (also according to SANS). However, considering that this port number was hardcoded into the malware this may be a good indicator of compromise for Duqu 2.0.
Part of the malware with array of secret keywords
This 64-bit driver contains an internal DLL name, “termport.sys”, while the filename in the filesystem was “portserv.sys”. This most likely means that the attackers change filenames for different operations and detection of this attack should not solely rely on names of the files. The compilation timestamp is apparently fake here: “Jul 23 18:14:28 2004”. All the discovered driver files were located in “C:\Windows\System32\drivers\”.
Perhaps the most important part of this attack strategy is the digital signature used for the 64-bit driver. Because this is a mandatory requirement on 64-bit Windows systems, the driver had a valid digital signature. It was signed by “HON HAI PRECISION INDUSTRY CO. LTD.” (also known as “Foxconn Technology Group”, one of the world’s largest electronics manufacturers).
Digital signature of attacker’s driver
According to the information from the driver it was signed at 20:31 on 19.02.2015. Below are some more details provided by SysInternal’s sigcheck utility:Verified: Signed
Signing date: 20:31 19.02.2015
Publisher: HON HAI PRECISION INDUSTRY CO. LTD.
Description: Port Optimizer for Terminal Server
Product: Microsoft Windows Operating System
Prod version: 6.1.7601
File version: 6.1.7601 built by: WinDDK
According to Wikipedia “Foxconn Technology Group” is the world’s largest electronics contract manufacturer and is headquartered in Tucheng, New Taipei, Taiwan.
Major customers of Foxconn include or have included some of the world’s largest enterprises:
- Acer Inc.
- Apple Inc.
- BlackBerry Ltd.
- Motorola Mobility
Foxconn manufactures several popular https://en.wikipedia.org/wiki/Foxconn products including BlackBerry, iPad, iPhone, Kindle, PlayStation 4, Xbox One and Wii U.
The same certificate was used by the manufacturer to sign several WatchDog Timer Kernel drivers (WDTKernel.sys) for Dell laptops in February 2013.Conclusions
During our previous research into Stuxnet and Duqu we have observed digitally signed malware (using malicious Jmicron and Realtek certs). Stealing digital certificates and signing malware on behalf of legitimate businesses seems to be a regular trick from the Duqu attackers. We have no confirmation that any of these vendors have been compromised but our indicators definitely show that the Duqu attackers have a major interest in hardware manufacturers such as Foxconn, Realtek and Jmicron. This was confirmed in the 2014/2015 attacks, when we observed infections associated with hardware manufacturers from APAC, including ICS and SCADA computer equipment manufacturers.
Another interesting observation is that besides these Duqu drivers we haven’t uncovered any other malware signed with the same certificates. That rules out the possibility that the certificates have been leaked and are being used by multiple groups. It also seems to indicate the Duqu attackers are the only ones who have access to these certificates, which strengthens the theory they hacked the hardware manufacturers in order to get these certificates.
Finally, it’s interesting that the Duqu attackers are also careful enough not to use same digital certificate twice. This is something we have seen with Duqu from both 2011 and 2015. If that’s true, then it means that the attackers might have enough alternative stolen digital certificates from other manufacturers that are ready to be used during the next targeted attack. This would be extremely alarming because it effectively undermines trust in digital certificates.
Both Verisign and HON HAI have been informed about the use of the certificate to sign the Duqu 2.0 malware.IOC
Sample MD5 (portserv.sys): 92e724291056a5e30eca038ee637a23f
Serial number of Foxconn certificate used by Duqu attackers:
25 65 41 e2 04 61 90 33 f8 b0 9f 9e b7 c8 8e f8
Full certificate of the malicious driver:
Earlier this year, during a security sweep, Kaspersky Lab detected a cyber-intrusion affecting several of our internal systems.
Following this finding, we launched a large scale investigation, which led to the discovery of a new malware platform from one of the most skilled, mysterious and powerful groups in the APT world – Duqu. The Duqu threat actor went dark in 2012 and was believed to have stopped working on this project – until now. Our technical analysis indicates the new round of attacks include an updated version of the infamous 2011 Duqu malware, sometimes referred to as the stepbrother of Stuxnet. We named this new malware and its associated platform “Duqu 2.0”.
Some of the new 2014-2015 Duqu infections are linked to the P5+1 events and venues related to the negotiations with Iran about a nuclear deal. The threat actor behind Duqu appears to have launched attacks at the venues for some of these high level talks. In addition to the P5+1 events, the Duqu 2.0 group has launched a similar attack in relation to the 70th anniversary event of the liberation of Auschwitz-Birkenau.
In the case of Kaspersky Lab, the attack took advantage of a zero-day in the Windows Kernel, and possibly up to two other, currently patched vulnerabilities, which were zero-day at that time. The analysis of the attack revealed that the main goal of the attackers was to spy on Kaspersky Lab technologies, ongoing research and internal processes. No interference with processes or systems was detected. More details can be found in our technical paper.
From a threat actor point of view, the decision to target a world-class security company must be quite difficult. On one hand, it almost surely means the attack will be exposed – it’s very unlikely that the attack will go unnoticed. So the targeting of security companies indicates that either they are very confident they won’t get caught, or perhaps they don’t care much if they are discovered and exposed. By targeting Kaspersky Lab, the Duqu attackers probably took a huge bet hoping they’d remain undiscovered; and lost.
At Kaspersky Lab, we strongly believe in transparency, which is why we are going public with this information. Kaspersky Lab is confident that its clients and partners are safe and that there is no impact on the company’s products, technologies and services.
More details can be found below:
To check your network for Duqu’s 2.0 presence, you can also use the open IOC file available here.
Microsoft releases eight security bulletins today, updating a set of forty five software vulnerabilities. This month’s updates touch a smaller set of Microsoft software, but two of the Bulletins address kernel-level vulnerabilities and require a restart. Some are being exploited as a part of serious targeted attack activity:
- Windows Kernel, win32k.sys (MS15-061)
- Internet Explorer – critical
- Windows Media Player – critical
- Microsoft Common Controls
- Microsoft Office
- Active Directory Federation Services
- Exchange Server
Two are rated Critical (MS15-056 for Internet Explorer and MS15-057 for Windows Media Player) because of their remote code execution severity. The Internet Explorer bulletin alone fixes over 20 memory corruption vulnerabilities in the IE codebase.
Most interesting of all the bulletins this month turns out to be MS15-061, patching eight different software flaws in the kernel. In particular, cve-2015-2360 was a difficult find, and this 0day was reported by our own talented colleague Maxim Golovkin. This issue presented itself within win32k.sys, which fails to properly free memory after use. It might be rated “Important” as an escalation of privilege vulnerability, but defending against its deployment as a part of targeted attack activity is most certainly critical.
Please update your Windows systems asap.
This week we joined droves of vendors and executives in celebrating InfoSecurity Europe’s 20 year anniversary. The venue, the London Olympia, is a behemoth filled wall-to-wall with company banners, awkward sales pitches, gimmicky totebags, gift lightsabers, and ‘free’ prosecco readily exchanged for cloud security pitches.
This year, the organizers wisely decided to add a small conference annex under the banner of ‘Intelligent Defence’ with the intention of attracting a more content-oriented crowd. The talks were largely research-oriented and included a fair serving of IoT bashing and malware hunting.
Here we presented our ongoing research project on whitelisting titled ‘Wolf in Sheep’s Clothing: Your next APT is Already Whitelisted’ – stay tuned for an extensive analysis!
Intelligent Defence included notable presentations by Andrew Hay (OpenDNS), Daniel Mende (ENRW), and Sergey Bratus (Dartmouth). Hay gave us a preview of his ‘labor of love’ paper on IoT beaconing in the enterprise (found here), an extensive research into the domain queries common IoT products perform out of the box and their unregulated penetration into industry verticals.
Daniel Mende walked us through performing an analysis of proprietary network protocols, effectively lifting the veil of security by obscurity by not just showcasing the failure of this particular nameless protocol but also providing the crowd with a sense of the relative ease with which these protocols can be probed, dismantled, and effectively obviated.
Finally, Sergey Bratus shared a brilliant exposition of the complex relationship between defensive and offensive computing, partially defined in terms of ‘weird machines‘ to ease a widespread difficulty in describing the dynamics that enable fruitful InfoSec research – that difficulty subsequently leads to problematic regulatory over simplifications like the expansion of the Wassenaar arrangement currently under consideration.
Intelligent Defence is a strong step in the right direction for Europe’s largest InfoSec conference. We hope to see you there next time.