quote:

Stuxnet heeft drie speficieke payloads, zeg maar 'kernkoppen'. Uit onderzoek van Symantec blijkt dat twee van de drie aanvalsmodules alleen in werking treden als zij industriële frequentieregelaars tegenkomen die electromotoren aansturen die met extreme snelheden draaien. Boven de 800 Hz, dat is 48420 toeren per minuut (rpm). [...]

Er zijn bovendien maar heel weinig industriële processen waarbij dergelijke omwentelingssnelheid noodzakelijk zijn. De belangrijkste is uraniumverrijking. Maar zijn er geen andere industriële toepassingen met dergelijke toerentallen? Pompen, turbines? We vroegen het aan Adrie Huesman, universitair docent TU Delft van het Delft Center for Systems and Control.

"50.000 rpm is wel extreem hoog. Compressoren komen hier nog het dichtste bij, maar die komen meestal niet uit boven de 10.000 rpm. Met dat toerental kun je een druk opbouwen van 200 bar, dat is ongeveer de maximum gangbare druk in bijvoorbeeld de chemische industrie. Hogere snelheden zijn niet nodig en dus de investering niet waard, omdat het veel duurder wordt. Vanwege de extreme centrifugale krachten zijn dan speciale materialen nodig", legt Huesman uit.

"De Chinezen werken momenteel aan geavanceerde separatoren, maar die halen ook niet meer dan 10.000 rpm. Ik ken geen industriële applicaties die hogere toeren hebben dan dat."
bron

quote:

“The STL code [in Stuxnet] was sending down things like ‘word 47F and 1′,” Chien recalls. “And you look at the frequency converter [manual], and it says, ‘To start the frequency converter, send down the word 47F and set this value to 1. We were speechless.”

Based on information in the code, Stuxnet was targeting a facility that had 33 or more of the frequency converter drives installed, all operating at between 807Hz and 1,210Hz.

Stuxnet searches for a facility that has a minimum of 33 frequency converters installed.
The malware would sit quietly on the system doing reconnaissance for about two weeks, then launch its attack swiftly and quietly, increasing the frequency of the converters to 1,410Hz for 15 minutes, before restoring them to a normal frequency of 1,064Hz. The frequency would remain at this level for 27 days, before Stuxnet would kick in again and drop the frequency down to 2Hz for 50 minutes.

The drives would remain untouched for another 27 days, before Stuxnet would attack again with the same sequence. The extreme range of frequencies suggested Stuxnet was trying to destroy whatever was on the other end of the converters.

quote:

Op woensdag 15 februari 2012 20:59 schreef YuckFou het volgende:
Aangezien Resonancer een eigen topic aan heeft gemaakt kan ik deze wel even kapen
Ik zit te dubben of ik een [BNW] topic aan Stuxnet moet wijden, de code is inmiddels in ieder gevaal deels op t net gekomen en dus in handen van virusschrijvers en andere nerds, ik hoef denk ik niet te vertellen wat dit voor impact kan hebben als Anonymous in plaats van een ddos attack een derivaat van Stuxnet inzet om een bedrijf klem te zetten, dat kan heel verre gevolgen hebben....

quote:

Op woensdag 15 februari 2012 21:48 schreef J0kkebr0k het volgende:
Goed topic!

quote:

Op woensdag 15 februari 2012 22:57 schreef Bankfurt het volgende:
"Volgens vooraanstaand computerbeveiliger Symantec zijn sinds juli van dit jaar 63 pc's in Japan besmet geraakt met Stuxnet. Een computervirus dat is gekweekt om servers aan te vallen die geïsoleerd zijn van het internet".

quote:

Within a week of establishing the sinkhole, about 38,000 infected machines were reporting in from dozens of countries. Before long, the number would surpass 100,000. Stuxnet was spreading rapidly, despite signatures distributed by antivirus firms to stop it.

As Chien and O Murchu mapped the geographical location of the infections, a strange pattern emerged. Out of the initial 38,000 infections, about 22,000 were in Iran. Indonesia was a distant second, with about 6,700 infections, followed by India with about 3,700 infections. The United States had fewer than 400. Only a small number of machines had Siemens Step 7 software installed – just 217 machines reporting in from Iran and 16 in the United States.

The infection numbers were way out of sync with previous patterns of worldwide infections — such as what occurred with the prolific Conficker worm — in which Iran never placed high, if at all, in infection stats. South Korea and the United States were always at the top of charts in massive outbreaks, which wasn’t a surprise since they had the highest numbers of internet users. But even in outbreaks centered in the Middle East or Central Asia, Iran never figured high in the numbers. It was clear the Islamic Republic was at the center of the Stuxnet infection.

quote:

Op woensdag 15 februari 2012 23:04 schreef YuckFou het volgende:
Stuxnet fascineert me eigenlijk om twee redenen...

Enerzijds de techniek, als je erin duikt is het griezelig hoe ver ze zijn gegaan, de timing, de backdoors, de zero day exploits, de precisie van de code, een van de eerste opmerkingen die me altijd is bijgebleven is dat de code zo schoon en opgeruimd was.

quote:

Waar bij andere wormen en virussen vaak resten code of slordig geschreven code staat is Stuxnet clean van a tot z, met geen regel teveel, maar zeker ook niet te weinig.
Dat er niet zo maar hackertjes achter zaten was al snel duidelijk, en veel vingers wezen de kant van de VS en Israel op, maar voor zover nu bekend is, is er alleen een video van een afgezwaaide Israelische generaal die een vermelding van Sutxnet maakt, en dat is weer "volgens een bron" in Ha'aretz geopenbaard, maar voor [BNW] is dat even genoeg alhoewel ik de VS ook wel verdenk van hevige samenwerking hierbij....

Tweede punt is de code, die (deels) op t net is verschenen, SCADA systemen van Siemens blijken nog even kwetsbaar als voor Stuxnet, vaak beveiligt met een standaard of zelfs geen wachtwoord, wat misbruik bij een hack natuurlijk heel reëel maakt, zeker met een redelijk overacktief hackersnetwerk alla Anonymous of Lulzsec die zoals ze hebben laten zien niet terugdeinzen voor grote organisaties en bedrijven, en er is nogal een verschil tussen een ddos attack of het lamleggen van een industrieel proces als zo'n groepering z'n zin niet krijgt...

quote:

Op woensdag 15 februari 2012 23:44 schreef J0kkebr0k het volgende:
De eerste Stuxnet versie was een virus die niet gericht was op verspreiding via Internet en/of netwerken, omdat juist de target systemen niet op Internet zijn aangesloten vanwege het grote risico van buitenaf besmet te raken. De besmetting vond plaats via bijvoorbeeld een simpele USB stick en je kunt wel raden dat het niet zo simpel is om een USB stick bij een (Iraanse) kerncentrale binnen te krijgen en in een van de kritische systemen te proppen.

Simpelweg een besmette USB stick over het hek bij een kerncentrale werpen in de hoop dat een medewerker hem vind en uit nieuwsgierigheid naar de inhoud de stick in een systeem prikt, lijkt me niet aan de orde, dus er zal van binnenuit sprake zijn geweest van spionage.

Latere Stuxnet versies verspreidden zich wel via internet (peer to peer via Remote Procedure Call) waardoor vele systemen werden besmet. Soort van clusterbom. Echter, de systemen die echt cruciaal zijn en niet met de buitenwereld communiceren, zijn niet vatbaar voor dit virus.

quote:

Op woensdag 15 februari 2012 23:52 schreef Bankfurt het volgende:

[..]

Wat denk je van backdoors in de vorm van wireless software, ook in oude OS ? of datacommunicatie via het elektriciteitsnetwerk ?

quote:

Op woensdag 15 februari 2012 23:58 schreef J0kkebr0k het volgende:

[..]

Dan moet die datacommunicatie wel mogelijk zijn en het "ontvangende" systeem een netwerkadapter hebben die dit mogelijk maakt. Dat lijkt me in verreweg de meeste systemen niet aan de orde.

quote:

Wat bedoel je met backdoors in de vorm van wireless software?

quote:

Op woensdag 15 februari 2012 23:58 schreef J0kkebr0k het volgende:

[..]

Dan moet die datacommunicatie wel mogelijk zijn en het "ontvangende" systeem een netwerkadapter hebben die dit mogelijk maakt. Dat lijkt me in verreweg de meeste systemen niet aan de orde.

Wat bedoel je met backdoors in de vorm van wireless software?

quote:

14feb2012 - Experts say Iran has 'neutralized' Stuxnet virus

* Computer virus disrupted Iran's centrifuges

* More advanced attacks in the offing?

By Mark Hosenball

Feb 14 (Reuters) - Iranian engineers have succeeded in neutralizing and purging the computer virus known as Stuxnet from their country's nuclear machinery, European and U.S. officials and private experts have told Reuters.

The malicious code, whose precise origin and authorship remain unconfirmed, made its way as early as 2009 into equipment controlling centrifuges Iran is using to enrich uranium, dealing a significant but perhaps temporary setback to Iran's suspected nuclear weapons work.

Many experts believe that Israel, possibly with assistance from the United States, was responsible for creating and deploying Stuxnet. But no authoritative account of who invented Stuxnet or how it got into Iran's centrifuge control equipment has surfaced.

U.S. and European officials, who insisted on anonymity when discussing a highly sensitive subject, said their governments' experts agreed that the Iranians had succeeded in disabling Stuxnet and getting it out of their machinery.

The officials declined to provide any details on how their governments verified that the Iranians had ultimately defeated the virus. It was not clear when it occurred but secrecy on the subject has been so tight that news is only now emerging.

Some officials said they believe that the Iranians were helped in their efforts by Western cybersecurity experts, whose detailed technical analyses of Stuxnet's computer code have circulated widely on the Internet.

Once the Iranians became aware that their equipment had been infected by the virus, experts said it would only have been a matter of time before they would have been able to figure out a way of shutting down the malicious code and getting it out of their systems.

"If Iran would not have gotten rid of Stuxnet by now (or even months ago), that would indicate that they were complete idiots," said German computer security consultant Ralph Langner. Langner is regarded as the first Western expert to identify the ultra-complex worm and conclude that it was specifically targeted toward equipment controlling Iranian nuclear centrifuges.

Peter Sommer, a computer security expert based in Britain, said that once Iran had detected the presence of the worm and figured out how it worked, it shouldn't have been too hard for them to disable it.

"Once you know that it's there it's not that difficult to reverse engineer... Neutralization of Stuxnet, once its operation is understood, would not be that difficult as it was precisely engineered to disrupt a specific item of machinery.

"Once Stuxnet's signature is identified it can be eliminated from a system," Sommer added.

Private experts say that however well-crafted the original Stuxnet was, whoever created it probably would have to be even more clever if they want to try to supplant it with new cyber-weapons directed at Iran's nuclear program.

"Aspects of Stuxnet could be re-used, but it is important to understand that its success depended not only on 'clever coding' but also required a great deal of specific intelligence and testing. It was the first known highly-targeted cyber-weapon, as opposed to more usual cyber weapons which are more diffuse in their targeting," Sommer said.

'CAT AND MOUSE GAME'

David Albright, a former United Nations weapons inspector who has extensively investigated Iran's nuclear program for the private Institute for Science and International Security, which he leads, said that spy agencies would have to go back to the drawing board if they're intent on continuing to try to hobble Iran's nuclear program via cyber-warfare.

Iran says that its nuclear program is for peaceful purposes but many Western officials believe it is seeking to build nuclear weapons.

"I would assume that once Iran learned of Stuxnet, then intelligence agencies looked at this method of cyber attack as compromised regardless of how long it has taken Iran to neutralize it. It is a cat and mouse game."

But Albright added that "intelligence agencies have likely been looking at more advanced forms of attack for a couple of years that they hope will catch the Iranians unprepared."

Reports first surfaced in 2010 that Iran's main nuclear enrichment facility at Natanz was hit by Stuxnet, though some experts later said it likely first was deployed a year earlier. Experts who later analyzed the Stuxnet code said it was engineered specifically to attack machines made by the German company Siemens that control high-speed centrifuges, used to purify uranium which can fuel a nuclear weapon.

Tehran accused the United States and Israel of planting the virus. In November 2010, Iranian President Mahmoud Ahmadinejad said that malicious software had created problems in some of Iran's uranium enrichment centrifuges, although he said the problems had been solved.

Several experts said, however, that while they believed the virus' potency waned over time, they had not heard confirmation that the Iranians had defeated and purged it.

Experts say the inventors of Stuxnet had to be unusually clever because the centrifuge control equipment at which it was targeted - and which it apparently succeeded in hobbling - was entirely cut-off from the Internet. So not only did the worm's creators have to write a code that would cause targeted equipment to malfunction but they had to figure out a way to physically introduce the code into a "closed system."

Most experts think the virus was somehow introduced into Iran's control systems via some kind of computer thumb drive.

European and U.S. experts have said that they believe that Stuxnet, at least for a time, caused serious malfunctions in the operations of Iranian nuclear centrifuges.

Iran and its antagonists today appear to be engaged in multiple levels of clandestine warfare, with unknown assailants killing Iranian nuclear scientists and, in the last few days, bomb attacks on Israeli embassy personnel in India and Georgia. Israel has blamed Iran.

http://www.reuters.com/ar(...)dUSL2E8DE9NL20120214

quote:

Op woensdag 15 februari 2012 23:52 schreef Bankfurt het volgende:

[..]

Wat denk je van backdoors in de vorm van wireless software, ook in oude OS ? of datacommunicatie via het elektriciteitsnetwerk ?

quote:

Op donderdag 16 februari 2012 01:57 schreef Dhalsim het volgende:

[..]

Ik maak alleen maar gebruik van het stopcontact voor mijn lokale netwerk. Het is dan wel via het het reguliere ethernet protocol maar ik zou het eerlijk gezegd vreemd vinden wanneer het elektriciteitsnet niet gebruikt zou worden voor talloze andere communicatie doeleinden die minder standaard zijn.

quote:

Op donderdag 16 februari 2012 13:22 schreef Boswachtertje het volgende:
zeer interessant.. hier wil ik wel wat meer van weten!

quote:

Op donderdag 16 februari 2012 13:30 schreef UncleScorp het volgende:

[..]

Langs de andere kant hoop ik dat we hier niet meer van horen in de toekomst ...
A new type of warfare is born ...

quote:

Op woensdag 15 februari 2012 21:35 schreef YuckFou het volgende:

Dit is dan misschien een artikel wat wel lijkt te onderschrijven dat Stuxnet is gefabriceerd door de Israeli's , maar dan nog steeds geënt op het slopen van Iraanse Centrifuges...

quote:

The covert American program, started in early 2008, includes renewed American efforts to penetrate Iran’s nuclear supply chain abroad, along with new efforts, some of them experimental, to undermine electrical systems, computer systems and other networks on which Iran relies. It is aimed at delaying the day that Iran can produce the weapons-grade fuel and designs it needs to produce a workable nuclear weapon.
http://www.nytimes.com/20(...)0natanz&st=cse&scp=1

quote:

The other technical mystery is that Tepco engineers suggested that the electric power inside the plant was knocked out by something other than the tsunami. I have pointed to this possibility early on, that the quake and control disruptions could have made the control computers vulnerable to the Stuxnet virus.
http://www.globalresearch.ca/index.php?context=va&aid=24364

quote:

Op vrijdag 17 februari 2012 11:36 schreef Resonancer het volgende:
Ik vraag me vnl af, kan het zo zijn dat dit " per ongeluk " in de Japanse centrales terecht is gekomen?

quote:

"Investigators analyzed log files and connections to foreign Internet protocol addresses within the utility’s computer system, said the source, who was not authorized to speak for attribution. “No indictors of malicious activity were found” in the computer system of the Curran-Gardner Townships Public Water District in Springfield, the source said."

quote:

Stuxnet/Duqu: The Evolution of Drivers
We have been studying the Duqu Trojan for two months now, exploring how it emerged, where it was distributed and how it operates. Despite the large volume of data obtained (most of which has yet to be published), we still lack the answer to the fundamental question - who is behind Duqu?

In addition, there are other issues, mostly to do with the creation of the Trojan, or rather the platform used to implement Duqu as well as Stuxnet.

In terms of architecture, the platform used to create Duqu and Stuxnet is the same. This is a driver file which loads a main module designed as an encrypted library. At the same time, there is a separate configuration file for the whole malicious complex and an encrypted block in the system registry that defines the location of the module being loaded and name of the process for injection.


We believe Duqu and Stuxnet were simultaneous projects supported by the same team of developers.

Several other details have been uncovered which suggest there was possibly at least one further spyware module based on the same platform in 2007-2008, and several other programs whose functionality was unclear between 2008 and 2010.

These facts significantly challenge the existing "official" history of Stuxnet. We will try to cover them in this publication, but let us first recap the story so far.

The ‘official’ Stuxnet story
Let me start with a question: how many Stuxnet driver files are known? As of today, the correct answer would be four. See below for more information about them.

File name Size (bytes) Compilation date Where and when it was used Digital signature/signing date
Mrxcls.sys 19840 01.01.2009 Stuxnet (22.06.2009) No
Mrxcls.sys 26616 01.01.2009 Stuxnet (01.03.2010/14.04.2010) Realtek, 25.01.2010
Mrxnet.sys 17400 25.01.2010 Stuxnet (01.03.2010/14.04.2010) Realtek, 25.01.2010
Jmidebs.sys 25552 14.07.2010 Presumably, Stuxnet Jmicron, unknown

The first modification of the Stuxnet worm, created in 2009, used only one driver file – mrxcls.sys without a digital signature.

In 2010, the authors created the second driver mrxnet.sys (to hide the worm’s component files on USB drives) and equipped mrxnet.sys and mrxcls.sys drivers with digital certificates from Realtek. The mrxnet.sys driver is of no great significance to our story, as it is a separate module not included into the general architecture of the platform.

On 17 July 2010, ESET detected another driver “in the wild" - jmidebs.sys - which was very similar to the already known mrxcls.sys, but had been created just three days before it was discovered. This driver was backed with a new certificate - this time from Jmicron.

Until recently it was unclear what the purpose of this file was, but popular opinion held that it was related to Stuxnet. One theory is that the Stuxnet C&C was trying to replace the old version with the Realtek certificate with a new one. In doing so, the authors of the worm were either hoping to prevent it being picked up by antivirus programs, or were replacing a certificate which had been blocked.

Unfortunately, this theory has not been confirmed - Jmidebs.sys has never been detected anywhere. A new version of Stuxnet capable of installing the file has also not been found.

This is the official history of Stuxnet. However, as I mentioned above, in the course of our research we have discovered new evidence which will be discussed below.

Previously unknown drivers
rtniczw.sys
While analyzing a user incident involving Duqu, we discovered something new – something that could, potentially, affect the whole Stuxnet story as we know it.

A strange file was discovered on the victim’s computer, which was detected by our antivirus engine as Rootkit.Win32.Stuxnet.a. This verdict was supposed to correspond to the known file mrxcls.sys described above, but the detected file’s name and checksum were different!

The file was rtniczw.sys, 26,872 bytes in size, MD5 546C4BBEBF02A1604EB2CAAAD4974DE0.

The file was a little larger than mrxcls.sys, which had a Realtek digital signature. This implied that rtniczw.sys also had a digital signature. We managed to get a copy of the file, and we were amazed to find that it used the same Realtek certificate, but with a different file signing date from mrxcls.sys: rtniczw.sys was signed on 18 March 2010, while the mrxcls driver had been signed on 25 January of the same year.

In addition, rtniczw.sys used a registry key and configuration data block that was not used in Stuxnet. Stuxnet used the key “MRxCls” and the value “Data”, while in the case of rtniczw.sys, the key was “rtniczw” and the value was “Config”.

Detailed analysis of the code found in rtniczw.sys identified no other differences from the ‘reference’ driver: this was the same mrxcls.sys file, created in the same year, on the same day and hour – on 1 January 2009.

We searched for additional information about other users who had the same file, but were unable to find anything! Moreover, we could find no information at all about the file’s name (rtniczw.sys) or its MD5 in any search engine. The file had been identified only once: it had been sent for scanning to VirusTotal from China in May 2011.

Apparently, the system that we were studying had been infected in late August 2011. It should be noted that we did not find a Stuxnet infection on the system: no additional files from the Stuxnet kit had been found. However, we did find Duqu files.

We came to the conclusion that there could be other driver files similar to the “reference” file mrxcls.sys, which are not among known variants of Stuxnet.

rndismpc.sys
A check in our malware collection helped identify another interesting file that was included in the collection over a year ago. The file is named rndismpc.sys, it is 19,968 bytes in size, MD5 9AEC6E10C5EE9C05BED93221544C783E.



This turned out to be another driver, with functionality very nearly identical to that of mrxcls.sys apart from the following exceptions:

rndismpc.sys uses a registry key that is different from the keys used by both mrxcls and rtniczw – it is the key “rndismpc” with the value “Action”;
it uses an encryption key that is different from that used by mrxcls/rtniczw – 0x89CF98B1;
the file’s compilation date is 20 January 2008, i.e. a year before mrxcls/rtniczw were created.
Like rtniczw.sys, the file rndismpc.sys had never been encountered on our users’ machines. We do not know which malicious program installed it or which main module it was supposed to work with.

The connecting link: mrxcls.sys —> jmidebs.sys —>Duqu drivers
The data obtained and the available information about the drivers used in Duqu (see The Mystery of Duqu, Part One and Part Two) can be summed up in the table below:

Name Size Compi-
lation date Main module Encryption key Registry key Value Device
name
rndismpc.sys 19968 20.01.
2008 Unknown 0x89CF98B1 rndismpc “Action” “rndismpc”
mrxcls.sys 19840 01.01.
2009 Stuxnet.a 0xAE240682 MRxCls “Data” “MRxClsDvX”
mrxcls.sys (signed) 26616 01.01.
2009 Stuxnet.b/.c 0xAE240682 MRxCls “Data” “MRxClsDvX”
rtniczw.sys (signed) 26872 01.01.
2009 Unknown 0xAE240682 rtniczw “Config” “RealTekDev291”
jmidebs.sys (signed) 25502 14.07.
2010 Unknown 0xAE240682 jmidebs “IDE” {3093983-109232-29291}
<name>.sys* Different 03.11.
2010 Duqu 0xAE240682 <name> “FILTER” {3093AAZ3-1092-2929-9391}
<name>.sys* Different 17.10.
2011 Duqu 0x20F546D3 <name> “FILTER” {624409B3-4CEF-41c0-8B81-7634279A41E5}

*Known Duqu drivers have unique file names for each of the variants. Their functionality, however, is absolutely identical.

According to our analysis, jmidebs.sys is the connecting link between mrxcls.sys and the drivers later used in Duqu.

The code of mrxcls and jmidebs drivers is largely similar. Some small differences may be due to different settings and minimal changes in the source code, while the point of the code remains the same.

However, more significant changes can be found in several functions:

The service function which obtains addresses of API functions: The version in mrxcls uses the function MmGetSystemRoutineAddress for this purpose and the respective text names of the addresses of incoming API functions. The version in jmidebs calls its own functions to obtain API addresses using hash-sums of their names. The same functions are used in Duqu drivers, while the list of functions’ hashes is twice as long.
The function which creates stubs to inject PNF DLL into processes: The mrxcls version uses a stub with a total size of 6332 bytes. The jmidebs and Duqu drivers use stubs with a total size of 7061 bytes. The code used in the stub modules for these drivers is identical, but has different compilation dates.
Mrxcls (Stuxnet) jmidebs Duqu
API RtlGetVersion, KeAreAllApcsDisabled, obtained by calling MmGetSystemRoutineAddress RtlGetVersion, KeAreAllApcsDisabled, PsGetProcessSessionId, PsGetProcessPeb obtained with their own functions Similar to jmidebs, 4 more functions added
Injected EXE 6332 Jan 01 22:53:23 2009 7061 Jul 14 13:05:31 2010 7061 Different compilation dates

Driver evolution
We have mapped out the links between known drivers whose evolution and key stages of development are easy to track.

Driver evolution from 2008 to 2011

rndismpc.sys, rtniczw.sys and jmidebs.sys
As you can see from the diagram, it is not known which malicious program interacted with the following three drivers: rndismpc.sys, rtniczw.sys and jmidebs.sys. The obvious question would be: were they used in Stuxnet? In our opinion, the answer would have to be ‘no’.

First of all, if they had been used in Stuxnet, they would have left a far bigger footprint than the individual cases we have detected. Secondly, there hasn’t been a single variant of Stuxnet that is capable of interacting with these drivers.

The file rtniczw.sys was signed on 18 March 2010, but on 14 April 2010 the Stuxnet authors created a new variant of the worm that made use of the “reference” mrxcls.sys. It is obvious that rtniczw.sys was intended for some other use. The same can be said of jmidebs.sys. We believe that the three drivers are only indirectly related to Stuxnet and can safely be erased from Stuxnet history.

Then there is another question: could these drivers have been used with Duqu?

There is no clear-cut answer here. Although all known variations of Duqu are from the period November 2010-October 2011, we believe there were earlier versions of the Trojan spy created to steal information. The three drivers in question could easily have been used in early versions of Duqu or with other Trojans based on the Stuxnet/Duqu platform. Like Duqu, those Trojans were most probably used in targeted attacks before the appearance of Stuxnet (dating back to at least 2008), both while it was active and after its C&C was shut down. They were likely to have been parallel projects, and Stuxnet was subsequently based on that accumulated experience and the code that had already been written. It seems highly unlikely that this was the only project that its authors were involved in.

The driver creation process
Let’s try to imagine what the driver creation process looks like. A few times a year the authors compile a new version of a driver file, creating a reference file. The primary purpose of this file is to load and execute a main module, which is created separately. It could be Stuxnet, or Duqu or something else.

When it is necessary to use a driver for a new module, the authors use a dedicated program to modify information in the driver’s “reference” file, i.e. its name and service information as well as the registry key and its value.

It’s important to note that they tweak ready-made files and don’t create a new one from scratch. This means they can make as many different driver files as they like, each having exactly the same functionality and creation date.

Depending on the aim of the attack and the Trojan’s victim, several driver files can then be signed with legitimate digital certificates whose origins remain unknown.

Conclusion
From the data we have at our disposal, we can say with a fair degree of certainty that the “Tilded” platform was created around the end of 2007 or early 2008 before undergoing its most significant changes in summer/autumn 2010. Those changes were sparked by advances in code and the need to avoid detection by antivirus solutions. There were a number of projects involving programs based on the “Tilded” platform throughout the period 2007-2011. Stuxnet and Duqu are two of them – there could have been others, which for now remain unknown. The platform continues to develop, which can only mean one thing – we’re likely to see more modifications in the future.
bron

quote:

Researchers Release Exploits for Critical Infrastructure Software

MIAMI, Florida — A group of researchers has discovered serious security holes in six top industrial control systems used in critical infrastructure and manufacturing facilities and, thanks to exploit modules they released on Thursday, have also made it easy for hackers to attack the systems before they’re patched or taken offline.

The vulnerabilities were found in widely used programmable logic controllers (PLCs) made by General Electric, Rockwell Automation, Schneider Modicon, Koyo Electronics and Schweitzer Engineering Laboratories.

PLCs are used in industrial control systems to control functions in critical infrastructure such as water, power and chemical plants; gas pipelines and nuclear facilities; as well as in manufacturing facilities such as food processing plants and automobile and aircraft assembly lines.

The vulnerabilities, which vary among the products examined, include backdoors, lack of authentication and encryption, and weak password storage that would allow attackers to gain access to the systems. The security weaknesses also make it possible to send malicious commands to the devices in order to crash or halt them, and to interfere with specific critical processes controlled by them, such as the opening and closing of valves.

As part of the project, the researchers worked with Rapid7 to release Metasploit exploit modules to attack some of the vulnerabilities. Metasploit is a tool used by computer security professionals to test if their networks contain specific vulnerabilities. But hackers also use the same exploit tool to find and gain access to vulnerable systems.

“We felt it was important to provide tools that showed critical infrastructure owners how easy it is for an attacker to take control of their system with potentially catastrophic results,” said Dale Peterson, founder of DigitalBond, the SCADA security company that led the research.

quote:

The vulnerabilities were discovered by a team of six researchers as part of DigitalBond’s Project Basecamp. The researchers included Reid Wightman, who works for DigitalBond, and five independent researchers who volunteered their time to examine the systems — Dillon Beresford, Jacob Kitchel, Ruben Santamarta and two unidentified researchers whose companies didn’t want them publicly associated with the work.

The vulnerable products include:

General Electric D20ME
Koyo/Direct LOGIC H4-ES
Rockwell Automation/Allen-Bradley ControlLogix
Rockwell Automation/Allen-Bradley MicroLogix
Schneider Electric Modicon Quantum
Schweitzer SEL-2032 (a communication module for relays)

The researchers were asked to focus on several attack categories, based on vulnerabilities previously discovered in other PLCs — such as ones Beresford found last year in popular PLCs made by Siemens.

Those included a hardcoded password, a backdoor inadvertently left in the system by company engineers and lack of strong authentication gateways that would prevent a non-legitimate user from sending malicious commands to the Siemens PLC.

It was a PLC made by Siemens that was targeted by the Stuxnet worm, a sophisticated piece of malware discovered last year that was designed to sabotage Iran’s uranium enrichment program. During a talk at S4 on Wednesday, industrial control system security expert Ralph Langner — one of the leading experts on Stuxnet — described how a read/write capability the Siemens programmers put in their system was leveraged by the attackers to capture legitimate data on the Siemens system in order to play it back to operator monitors so that administrators at the targeted plant would see only legitimate data on their screens and think the plant was functioning normally while it was being sabotaged.

Of the systems discussed on Thursday, the General Electric D20ME was the most expensive PLC the researchers examined — costing about $15,000 — and had the most vulnerabilities. Wightman referred to his findings on the system as a “bloodbath” and said it took him just 16 hours to uncover the most glaring vulnerabilities.

He found that the system used no authentication to control the uploading of “ladder logic” to program the PLC. Backdoors in the system also allowed him to list processes, see where in memory they lived and to read and write to memory. He also had access to the configuration file, which listed, among other things, usernames and passwords that would allow an attacker to gain access to the system using legitimate credentials. Basic buffer overflow flaws in the system could also be used to crash it.

While a number of the systems the group tested used vulnerable web servers, the GE system did not have one at all. “Thank goodness, because if there was [one] I’m sure it would be done poorly, given everything else,” Wightman said.

The GE PLC is nearly two decades old but is still used in electric substations for power generation and in other key critical infrastructure systems. GE has said that it plans to release a new, more secure, version of the product this year, but it’s unclear whether that version fixes any of the vulnerabilities uncovered by the researchers. The company has said in a product bulletin published in 2010 that it has “no plans to develop additional cyber security features in previous generation D20 products due to limitations in the hardware and software platforms,” which leaves current customers using those systems potentially open to attack.

A GE spokesman said he couldn’t comment on the specific vulnerabilities uncovered until the company had more time to examine them.

“We want to take a look at the data they have and what are exactly the claims and make sure we investigate the product,” said Greg McDonald, spokesman for GE Digital Energy Business. He said he didn’t know offhand if the new version the company is working on fixes any of the vulnerabilities disclosed by the researchers.

The researchers found that the Koyo Direct Logic system, like the GE system, does not encrypt communication or require digitally signed messages, allowing an attacker to intercept commands and replay them to the PLC to take control of it. A web server used with the device also lacks basic authentication, allowing an attacker to reconfigure it to change basic settings such as the IP address and email alerts.

The Koyo system, however, is slightly more secure than the GE system, in that it at least requires a passcode for downloading and uploading ladder logic to the device. But Wightman said the system requires that the passcode start with the letter “A” and contain 7 digits between 0 and 9, making it easy to crack it by rapidly testing possible passwords, a method known as “bruteforcing.” Wightman said his group hopes to have a Metasploit module to bruteforce the passcode by Valentine’s Day.

“Just because I love that day and I want the vendors to love that day, too,” he said.

The Modicon Quantum system, another expensive key system for critical infrastructure that costs about $10,000, also has no authentication to prevent someone from uploading ladder logic and has about 12 backdoor accounts hard coded into it that have read/write capability. The system also has a web server password that is stored in plaintext and is retrievable via an FTP backdoor.

The Rockwell/Allen-Bradley and Schweitzer systems had similar vulnerabilities.

Wightman’s talk was not without controversy. Kevin Hemsley, a senior security analyst for the DHS’s Industrial Control System Computer Emergency Response Team and who was present at the conference, raised the issue that Wightman and his group hadn’t disclosed the vulnerabilities to the vendors in advance of his talk so that they could be prepared with patches or mitigation techniques.

Wightman and Peterson said they wanted to avoid the kind of situation that Beresford ran into last year when Siemens issued statements to customers downplaying the vulnerabilities he’d found and then swooped in at the last minute before his scheduled presentation to persuade him to cancel it until the company had more time to prepare patches.


“I didn’t want a vendor to jump out in front of the announcement with a PR campaign to convince customers that it wasn’t an issue they should be concerned with,” Wightman said.

Peterson added that “a large percentage of the vulnerabilities” the researchers found were basic vulnerabilities that were already known to the vendors, and that the vendors had simply “chosen to live with” them rather than do anything to fix them.

“Everyone knows PLC’s are vulnerable, so what are we really disclosing?” he said. “We’re just telling you how vulnerable they are.”

Marty Edwards, director of DHS’s Control Systems Security Program, wouldn’t comment on the release of the exploits and vulnerability information other than to say that the department “does not encourage the release of sensitive vulnerability information until a validated solution is available for distribution.”

“To better secure our nation’s critical infrastructure, DHS always supports the coordinated disclosure of vulnerability information—after we have provided actionable solutions and recommendations to our industry partners,” Edwards said in a statement.

Another DHS official attending the conference said that in releasing exploits before vendors and customers could mitigate them, the researchers were exposing the systems to attack by low-level hackers who are looking to cause mayhem.

“We have so many of these little scriptkiddies that are looking at these things and that are associating themselves with these anarchist groups,” said the official, who talked to Wired on condition that his name not be used since he was not authorized to speak to the press. “They want to create problems, and they’re just trying to figure out how. And that’s very concerning.”

quote:

Nou ben ik best wel een geek (nerd zelf volgens mn vriendje ) maar ik moet hier even pas op de plaats maken, nieuwe drivers? speciaal gemaakt om dit/deze wormen functies te geven die nog niet bestaan, is dat nieuw? Of gebeurt dat ook bij andere wormen? Ik dacht dat wormen en aanverwante meestal gebruik maakten van bestaande DLL's en die op een manier gebruiken die oneigenlijk is, of gebeurt dit vaker?

quote:

"Stuxnet en Duqu afkomstig uit digitale wapenfabriek"
_{29-12-2011,10:16 doorRedactie}

De Stuxnetworm en Duqu-virus zijn niet alleen door hetzelfde team gemaakt, ze zijn afkomstig van een speciaal platform voor supermalware dat sinds 2007 in ontwikkeling is. Dat stelt het Russische anti-virusbedrijf Kaspersky Lab in een technische analyse op het eigen weblog. "We denken dat Duqu en Stuxnet gelijktijdige projecten waren, ondersteund door hetzelfde ontwikkelteam", stellen Alexander Gostev en Igor Soumenkov.

Stuxnet was een zeer geavanceerde worm die verschillende Windows-lekken gebruikte om het Iraanse nucleaire programma te ontregelen. Duqu werd dit jaar ontdekt en zou gebruikt zijn om bij een select aantal organisaties en bedrijven in te breken en daar zeer vertrouwelijke gegevens te stelen.

Platform
Aan de hand van gevonden bestanden stellen de analisten dat voor de ontwikkeling van de malware een platform werd gebruikt, wat 'Tilded' wordt genoemd. De ontwikkelaars gebruikten voor een nog onbekende reden steeds bestandsnamen die met een "~d" begonnen. Verder denken de analisten dat er mogelijk nog één andere spyware module is, gebaseerd op hetzelfde platform dat van 2007-2008 dateert, en verschillende andere programma's, waarvan het doel en functionaliteit onduidelijk zijn en die tussen 2008 en 2010 werden ontwikkeld.

Tijdens de analyse van Duqu ontdekte Kaspersky Lab aanwijzingen die een directe relatie met Stuxnet hebben. Op dit moment zijn er vier Stuxnet drivers bekend die de worm gebruikt. De eerste aanpassing van de worm werd gemaakt in 2009 en gebruikte één driver, mrxcls.sys, zonder digitale handtekening.

In 2010 ontwikkelden de makers een tweede driver, mrxnet.sys, die de bestanden van de worm op USB-sticks verborg, en voorzagen de mrxnet.sys en mrxcls.sys drivers van gestolen digitale certificaten, die bij hardwarefabrikant Realtek werden buitgemaakt. Op 17 juli vorig jaar werd een andere driver ontdekt, jmidebs.sys, die erg veel leek op mrxcls.sys, maar gesigneerd was met een gestolen certificaat van hardwarefabrikant Jmicron.

Stuxnet
Op één van de computers die met het Duqu-virus besmet waren, werd een vreemd bestand ontdekt, wat de virusscanner als Rootkit.Win32.Stuxnet.a detecteerde. Dit zou moeten duiden op de mrxcls.sys driver, maar in dit geval waren de bestandsnaam en checksum van het vreemde bestand verschillend. De tot dan toe onbekende rtniczw.sys driver was iets groter dan mrxcls.sys en gebruikte ook een Realtek certificaat, maar de bestanden waren op een verschillende datum gesigneerd. Het nieuwe bestand werd op geen enkele andere computer aangetroffen. De enige andere referentie dateerde van mei dit jaar, toen iemand het bestand vanuit China voor controle naar VirusTotal stuurde.

"We kwamen tot de conclusie dat er andere driverbestanden konden zijn, gelijk aan het "referentiebestand" mrxcls.sys, die zich niet onder de bekende Stuxnet-varianten bevinden." Toen Kaspersky Lab hierop zocht, werd een ander bestand ontdekt dat een jaar geleden al aan de virusverzameling was toegevoegd. Dit bleek inderdaad een nieuwe Stuxnet-driver te zijn. Ook dit bestand, rndismpc.sys, was nog niet eerder op een andere machine aangetroffen.

De drie onbekende driver-bestanden, rndismpc.sys, rtniczw.sys en jmidebs.sys zijn volgens de virusbestrijder niet door Stuxnet gebruikt. "Waren ze door Stuxnet gebruikt, dan hadden ze een veel grotere afdruk achtergelaten dan de individuele gevallen die wij hebben ontdekt. Ten tweede is er geen enkele variant van Stuxnet die met deze drivers werkt", aldus de analisten. Die kunnen niet zeggen of de drivers dan wel door het Duqu-virus zijn gebruikt.

Toekomst
Aan de hand van de verzamelde informatie, stelt het anti-virusbedrijf dat het 'Tilded' platform eind 2007 of begin 2008 is ontwikkeld, voordat het in de zomer/herfst van vorig jaar de grootste veranderingen onderging. Die veranderingen zouden zijn aangewakkerd door ontwikkelingen in de code en de noodzaak om detectie door virusscanners te voorkomen.

"Er waren een aantal projecten tussen 2007 en 2011 waar programma's gebaseerd op het Tilded platform bij bij betrokken waren. Stuxnet en Duqu waren er twee van, er zouden er nog meer kunnen zijn, die tot nu toe nog onbekend zijn. Het platform blijft zich ontwikkelen, wat één ding kan betekenen, dat we in de toekomst waarschijnlijk meer aanpassingen zullen zien", besluiten de analisten.

quote:

"Stuxnet gemaakt in supergeheim lab"
_{10-01-2012,13:31 doorRedactie}
De zeer geavanceerde malware genaamd Duqu en Stuxnet, zijn gemaakt in een supergeheim laboratorium voor experimentele cyberwapens. Dat zegt Costin Raiu van anti-virusbedrijf Kaspersky Lab tegenover de Christian Science Monitor. De virusbestrijder deed uitgebreid onderzoek naar Duqu en ontdekte daarbij veel overeenkomsten met Stuxnet. Duqu werd ontwikkeld voor het stelen van zeer belangrijke gegevens, terwijl Stuxnet het Iraanse nucleaire programma ontregelde. "Het is net alsof ze een ionenkanon of zoiets ontwikkelen, alleen dan voor cyberoorlog. Dit zijn geen gewone wapens, maar de technisch meest geavanceerde wapens om cyberoorlog en cybersabotage te plegen."

Kaspersky Lab ontdekte dat Duqu en Stuxnet via een speciaal platform zijn ontwikkeld en dat er mogelijk nog meer varianten in omloop zijn. "Stel je voor dat je documenten wilt stelen", zegt Raiu. "Je hebt niet de sabotage mogelijkheden van Stuxnet nodig, dus die haal je eruit. In plaats daarvan gebruik je hetzelfde platform om gerichte malware te ontwikkelen, maar dan gericht op spionage. Dat is Duqu."

Atoombom
Beveiligingsexpert Ed Skoudis vergelijkt het met het Amerikaanse systeem voor het ontwikkelen van de atoombom. "Toen de VS de atoombom bouwde, was het niet de enige. We hadden een infrastructuur en platform om aanvullende wapens te bouwen." Volgens Skoudis beschikken de makers van Stuxnet over veel geld en slimme mensen. "Het is slim om dit soort wapens opnieuw te kunnen maken, en sommige achtergebleven vingerafdrukken laten dat zien."

Ook al wordt het software platform gebruikt voor Stuxnet en Duqu geïdentificeerd, zal dat nooit wijzen naar degene die de malware ook heeft gebouwd. "Ik denk niet dat het veel zal helpen", zegt Skoudis. "Maar deze ontdekking laat zien dat we meer van dit soort wapens kunnen verwachten, als er een militair doel zich voordat om het te gebruiken. We weten nu dat er een productiefaciliteit voor dit soort dingen is, en dat ze ook worden ingezet. Ik weet zeker dat we er meer zullen zien."

quote:

Op vrijdag 17 februari 2012 12:28 schreef J0kkebr0k het volgende:
@YuckFou: Wist niet dat jij een vrouw bent

quote:

Op vrijdag 17 februari 2012 12:28 schreef J0kkebr0k het volgende:
@YuckFou: Wist niet dat jij een vrouw bent

[..]

quote:

Op vrijdag 17 februari 2012 18:49 schreef YuckFou het volgende:

[..]

Ben ik ook niet

Verder kom ik er later op terug, zit zoals eerder gezegd in een retedrukke periode, maar probeer me tussen de bedrijven door in te lezen in de materie

quote:

Op vrijdag 17 februari 2012 18:53 schreef ChungLingSoo het volgende:

[..]

Waar haal je dat uit ?

Sowieso schaamteloze TVP omdat dit mijn terrein betreft.

quote:

Op vrijdag 17 februari 2012 18:53 schreef ChungLingSoo het volgende:
Sowieso schaamteloze TVP omdat dit mijn terrein betreft.

quote:

Op vrijdag 17 februari 2012 19:25 schreef J0kkebr0k het volgende:
Wel grappig overigens.... een homo die het retedruk heeft

Geintje natuurlijk.

quote:

Op vrijdag 17 februari 2012 19:55 schreef YuckFou het volgende:

[..]

Wat is jouw terrein? homo zijn of virussen?

[..]

quote:

_{zooo kansloos}

quote:

Op maandag 6 februari 2012 19:39 schreef dadgad het volgende:
"Hun angst is dat wij wakker worden en de leugen inzien."

quote:

Op vrijdag 17 februari 2012 21:15 schreef ChungLingSoo het volgende:

[..]

Computervirussen, hun werking en verspreiding zijn dingen waar ik me o.a. in specialiseer.
daarnaast zijn vrienden van mij PLC/SCADA programmers, dus we hebben dit allemaal wel een
beetje gevolgd
Nogmaals, het was alleen een TVP, dat Israel/UA of Rusland/China hier achter zit wordt nu
wel algemeen aangenomen. Ik wil alleen even kijken welke kant de discussie op gaat

quote:

Op vrijdag 17 februari 2012 22:41 schreef dadgad het volgende:
Hey YuckFou, wat is dat?

quote:

Op vrijdag 17 februari 2012 23:10 schreef YuckFou het volgende:

[..]

Cool&welkom!
Ik heb het bewust in [BNW] neergezet omdat hier wat richtinglozer gespeculeerd over kan worden over dingen, maar ik hou t graag reëel, dat anderen over wireless backdoors en andere bizarre zaken hier posten, mag, dat maakt dat je ook een andere kant op denkt dan alleen het "officieele" verhaal, zelf ben ik voorlopig druk genoeg met inlezen over Stuxnet en SCADA en dat kost sowieso veel tijd, maar mocht je wat nuttige aanvullingen hebben be my guest, en laat je niet afschrikken door t conspiracy sfeertje wat hier hangt, niet iedereen vermoed de mossad achter elke lantaarnpaal

[..]

quote:

Op vrijdag 17 februari 2012 21:15 schreef ChungLingSoo het volgende:

[..]

Computervirussen, hun werking en verspreiding zijn dingen waar ik me o.a. in specialiseer.
daarnaast zijn vrienden van mij PLC/SCADA programmers, dus we hebben dit allemaal wel een
beetje gevolgd

Nogmaals, het was alleen een TVP, dat Israel/UA of Rusland/China hier achter zit wordt nu
wel algemeen aangenomen. Ik wil alleen even kijken welke kant de discussie op gaat

[..]

Hij wil je...

quote:

Op zaterdag 18 februari 2012 02:26 schreef J0kkebr0k het volgende:

[..]

kansloze Chinees.. je weet geen kont van dit virus.... Maar je bent een virus-kenner.... Kom op... Bewijs jezelf...meestal jank je als een kleuter..... Dus ben benieuwd.

quote:

Op zaterdag 18 februari 2012 02:26 schreef J0kkebr0k het volgende:

[..]

kansloze Chinees..

quote:

Op vrijdag 17 februari 2012 23:30 schreef ChungLingSoo het volgende:
Ik ben hier al ZO veel langer dan jij, dus ik laat me echt niet afschrikken

quote:

Op zaterdag 18 februari 2012 02:26 schreef J0kkebr0k het volgende:
kansloze Chinees.. je weet geen kont van dit virus.... Maar je bent een virus-kenner.... Kom op... Bewijs jezelf...meestal jank je als een kleuter..... Dus ben benieuwd.

quote:

HBGary wanted to suppress Stuxnet research

HBGaryStuxnt

It is no secret that in recent days, Anonymous Operatives have released a cache of HBGary Federal internal emails to the public. Crowdleaks has discovered that within these communications, Aaron Barr received a copy of Stuxnet (a computer worm that targets the types of industrial control systems ICS that are commonly used in infrastructure supporting facilities) from McAfee on July 28, 2010.

In an effort to confirm this was in fact Stuxnet, Crowdleaks has decompiled some of the source code, which can be found here. Throughout the following emails it is revealed that HBGary Federal may have been planning to use Stuxnet for their own purposes.

SPOILER

In a message sent to all email account holders at HBGary.com, Charles Copeland, Lead Support Engineer at HBGary, Inc. writes:

from: Charles Copeland
to: all@hbgary.com
date: Sat, Sep 25, 2010 at 9:54 PM
subject: Stuxnet Worm Mailing List
Filter messages from this mailing list. mailed-byhbgary.com
hide details 9/25/10
Computerworld – Officials in Iran have confirmed that the Stuxnet worm infected at least
30,000 Windows PCs in the country, multiple Iranian news services reported on Saturday.

http://www.computerworld.(...)f_industrial_systems

I’ve already got a email asking about stuxnet, this came out late Friday. Does anyone have a dropper I have been unable to find it.

In another email sent directly to Aaron Barr, David D. Merritt writes:

from: David D. Merritt
to: Aaron Barr
date: Sun, Oct 3, 2010 at 9:35 PM
subject: Re: Hunter Killer Insanity 285mailed-bygmail.com
hide details 10/3/10
contacts over at TSA say that everybody has a copy…combine that with US CERTs vulnerability status and their own systems not meeting the spec….
i’m seeing TSA becoming a malware testbed…

Aaron Barr responds:

On Oct 3, 2010, at 10:13 PM, Aaron Barr wrote:
> Dave,
>
> We haven’t but I would be interested to talk to you some about the tie. I do have a decent amount of information on Stuxnet and would be interested to hear about the tie. Some of what I know about Stuxnet might be of interest. I think it would be best to discuss in a more closed space though.
>
> In doing a little research:
> http://diocyde.wordpress.(...)ll-them-their-pwned/
>
> While this guy can be a bit of a crackpot at times his post has more validity than fiction. Greg and I have brainstormed a bit in the past on how to conduct such an attack that would be very difficult to detect. Autonomous, single purpose malware with no C&C. As we have said the battle is on the edges either source of destination, everything else is or will become somewhat irrelevant or diminished in value.
>
> Aaron Barr
> CEO
> HBGary Federal, LLC
> 719.510.8478

In another message sent to all email account holders at HBGary.com by
Greg Hoglund, it’s made clear that HBGary wanted to hide their work on Stuxnet.

from: Greg Hoglund
to: all@hbgary.com
date: Sun, Sep 26, 2010 at 10:26 PM
subject: stuxnet mailing list
Filter messages from this mailing listmailed-byhbgary.com
hide details 9/26/10
All,
HBGary has no official position on Stuxnet. Please do not comment to the press on Stuxnet. We know nothing about Stuxnet.
-Greg Hoglund
CEO, HBGary, Inc.

In the most chilling strand of emails, we find that whatever HBGary was working on, it was in conjunction with the NSA.

Aaron Barr writes:

Hi Cheryl,
719.510.8478
Aaron
Sent from my iPad

Aaron Barr writes:

> From: Aaron Barr
> To: Peace, Cheryl D
> Sent: Mon Aug 09 13:54:23 2010
> Subject: Re: Number
>
> Hi Cheryl,
>
> It does. I haven’t met him personally. Our sister company does work
> in a few different pockets on the bldg. And i am on the extended NANA
> team. I recently joined to stand up HBGary federal, a related but
> separate company. We manage all the work that requires clearances.
> We exchange some technologies, but we have some separate developments
> as well. Mostly around threat intelligence and CNO/social media.
>
> I think there are some enabling tech to your mission but really need
> that qualified.
>
> Interested to run some of the stuxnet stuff by u as well.
>
> Aaron
>
>
> Sent from my iPhone

Cheryl Peace writes:

On Aug 9, 2010, at 9:27 AM, “Peace, Cheryl D” wrote:
>
>> Aaron
>> Did a little checking and we already do busy with you guys. Does the name
>> Tony Seager ring a bell?

Aaron Barr writes:

>> —–Original Message—–
>> From: Aaron Barr [mailto:aaron@hbgary.com]
>> Sent: Friday, August 06, 2010 10:56 AM
>> To: Peace, Cheryl D
>> Subject: Re: Number
>>
>> OK. If interested do you have some time to get together when you get back?
>> either next Friday or early the following week?
>> Aaron

Cheryl Peace writes:

>> On Aug 6, 2010, at 10:44 AM, Peace, Cheryl D wrote:
>>
>>> I am in Europe till mid next week

Aaron Barr writes:

>>> —–Original Message—–
>>> From: Aaron Barr [mailto:aaron@hbgary.com]
>>> Sent: Thursday, August 05, 2010 10:57 PM
>>> To: Peace, Cheryl D
>>> Subject: Re: Number
>>>
>>> Hi Cheryl,
>>>
>>> Can I schedule an appointment with you to come by and chat for a few
>>> minutes?
>>>
>>> Aaron

Cheryl Peace writes:

>>> On Jul 30, 2010, at 10:41 PM, Peace, Cheryl D wrote:
>>>
>>>> I am at Rao at the bar if you want to come by for a few. Meeting friends
>>> for a cocktail in a few
>>>> ————————–
>>>> Sent using BlackBerry

Arron Barr writes:

>>>> —– Original Message —–
>>>> From: Aaron Barr
>>>> To: Peace, Cheryl D
>>>> Sent: Fri Jul 30 20:02:44 2010
>>>> Subject: Number
>>>>
>>>> Cheryl,
>>>>
>>>> Sorry to bother you but do you have a minute to talk. I don’t have
>>>> your number handy. It will only take moment, but I have some
>>>> information for you.
>>>>
>>>> Aaron Barr
>>>> CEO
>>>> HBGary Federal
>>>> 7195108478

In a related internal email sent to Rich Cummings, CTO of HBGary, Inc., Greg Hoglund writes:

from: Greg Hoglund
to: Rich Cummings
date: Mon, Nov 16, 2009 at 9:30 PM
subject: Govt dropper in this word DOC, zipped up for youmailed-byhbgary.com
hide details 11/16/09

Phil, Rich,

I got this word doc linked off a dangler site for Al Qaeda peeps. I think it has a US govvy payload buried inside. Would be neat to REcon it and see what it’s about. DONT open it unless in a VM obviously. password is meatflower. Remove the .txt extension too. DONT let it FONE HOME unless you want black suits landing on your front acre. :-)

-Greg

quote:

Crowdleaks.org had a software engineer (whose name has been withheld) look at the Stuxnet binaries inside of a debugger and offer some insight on the worm. She informed us that most of the worms’ sources were using code similar to what is already publically available. She noted that the only remarkable thing about it was the 4 windows 0 days and the stolen certificates.

She says:

“A hacker did not write this, it appears to be something that would be produced by a team using a process, all of the components were created using code similar to what is already publically available. That is to say it’s ‘unremarkable’. This was created by a software development team and while the coders were professional level I am really not impressed with the end product, it looks like a picture a child painted with finger paints.”

When asked what type of organization likely wrote it, she stated:

“Probably a corporation by request of a government, it was clearly tested and put together by pro’s. It really looks like outsourced work.”

quote:

char __cdecl sub_10300();
void __stdcall DriverReinitializationRoutine(PDRIVER_OBJECT DriverObject, int a2, unsigned int a3);
NTSTATUS __stdcall DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath);
int __stdcall sub_1048A(int a1);
int __cdecl sub_10542();
// int __usercall sub_1056C<eax>(int a1<esi>);
// int __userpurge sub_105A0<eax>(int a1<ebx>, SIZE_T a2<edi>, int a3<esi>, const void *a4);
// int __usercall sub_105E4<eax>(LSA_UNICODE_STRING *a1<ecx>, int a2<edi>, int a3<esi>);
ULONG __thiscall sub_10638(LSA_UNICODE_STRING *this, ULONG a2, int a3);
// void __userpurge sub_1076E(int a1<ebx>, PVOID *a2);
signed int __fastcall sub_107A2(int a1, int a2);
int *__cdecl sub_107E8();
bool __stdcall sub_10886(int a1);
int __stdcall sub_108BE(const char *a1);
int __cdecl sub_1098E();
// signed int __usercall sub_109B0<eax>(int a1<edi>);
int __cdecl sub_10A3A();
// int __usercall sub_10A8A<eax>(int a1<edi>, int *a2<esi>);
// int __usercall sub_10AE2<eax>(int a1<esi>);
// int __usercall sub_10B36<eax>(int a1<esi>);
int __thiscall sub_10B68(int this);
int __stdcall sub_10BA2(int, int); // weak
signed int __cdecl sub_10BE8();
// int __userpurge sub_10BEC<eax>(int a1<ebp>, int a2, int a3);
// signed int __usercall sub_10C22<eax>(int a1<eax>);
signed int __stdcall sub_10CFE(int a1, int a2);
// void __usercall sub_10D7E(int a1<eax>);
// int __usercall sub_10DA8<eax>(int a1<ecx>, int a2<edi>, int a3<esi>);
void __stdcall sub_10DCC(int a1, HANDLE Handle, int a3);
void __stdcall NotifyRoutine(int a1, HANDLE Handle, int a3);
// int __userpurge sub_10FC4<eax>(int result<eax>, int a2);
RTL_GENERIC_TABLE *__cdecl sub_10FE6();
// PVOID __usercall sub_11028<eax>(int a1<eax>, RTL_GENERIC_TABLE *a2<edi>);
// signed int __usercall sub_11066<eax>(int a1<eax>, RTL_GENERIC_TABLE *a2<edi>);
// signed int __userpurge sub_110C0<eax>(RTL_GENERIC_TABLE *a1<eax>, int *a2);
bool __stdcall CompareRoutine(int a1, int a2, int a3);
PVOID __stdcall AllocateRoutine(int a1, SIZE_T NumberOfBytes);
void __stdcall FreeRoutine(int a1, PVOID P);
// int __usercall sub_1118A<eax>(int a1<ebx>, int a2<esi>);
// int __userpurge sub_111B4<eax>(int a1<eax>, int a2<ebx>, int a3);
// signed int __userpurge sub_11242<eax>(int a1<eax>, int a2, int a3);
// PVOID __userpurge sub_113C2<eax>(int a1<edi>, int a2, int a3);
// void __userpurge sub_1141E(int a1<eax>, int a2<ecx>, int a3<ebx>, int a4, int a5);
void __fastcall sub_114EC(int a1, int a2, int a3, int a4, int a5);
LONG_PTR __stdcall sub_11522(int a1, int a2, int a3, int a4, int a5);
PVOID __stdcall sub_11578(int a1);
PVOID __stdcall sub_11598(int a1);
// signed int __userpurge sub_115CC<eax>(const void *a1<eax>, int a2<ebx>, int a3);
signed int __thiscall sub_11718(int this, int a2, const void *a3);
__int32 __stdcall sub_1174A(int a1, int a2);
// char __usercall sub_117A8<al>(WCHAR *a1<eax>, int a2<ecx>);
// PVOID __usercall sub_1182C<eax>(ULONG a1<esi>);
// int __usercall sub_11864<eax>(HANDLE *a1<edi>);
signed int __stdcall sub_118E2(unsigned int a1, int a2);
char __fastcall sub_119AE(int a1, int a2);
// char __usercall sub_11A08<al>(int a1<edi>);
// int __userpurge sub_11A4A<eax>(int a1<eax>, int a2<ebx>, unsigned int a3);
// const char *__usercall sub_11ABC<eax>(const char *result<eax>, int a2<ecx>);
int __stdcall sub_11B04(int a1, const char *a2, unsigned int a3, int a4, int a5);
int *__cdecl sub_11C14();
int __stdcall sub_11CCC(int a1);
char __stdcall sub_11D46(int a1, unsigned int a2);
// NTSTATUS __userpurge sub_11D62<eax>(LSA_UNICODE_STRING *a1<eax>, PUNICODE_STRING ValueName, int a3);
int __stdcall sub_11DD6(int, PUNICODE_STRING ValueName, int); // idb
// int __usercall sub_11EC6<eax>(char a1<al>, int a2<ecx>, unsigned int a3<esi>);
int __stdcall sub_11F42(int, int, HANDLE Handle); // idb
// int __userpurge sub_11FC0<eax>(int a1<esi>, int a2, int a3);
int __stdcall sub_12000(HANDLE Handle, PVOID ProcessInformation); // idb
// int __userpurge sub_12094<eax>(int a1<ebx>, int a2<edi>, int a3);
// LONG_PTR __usercall sub_120CC<eax>(PVOID Object<ecx>, LONG_PTR result<eax>);
int __cdecl sub_120DE(int a1);
int __cdecl sub_1210F(int a1, unsigned int a2);
// signed int __usercall sub_1216B<eax>(int a1<eax>, unsigned int a2<ebx>);
signed int __cdecl sub_121E1(int a1, int a2, int a3);
signed int __cdecl sub_122B3(int a1, unsigned int a2);
bool __cdecl sub_122D0(int a1, unsigned int a2, int a3, int a4);
// signed int __usercall sub_12323<eax>(unsigned int a1<eax>, int a2, int a3, unsigned __int16 a4);
signed int __cdecl sub_1236B(int a1, int a2);
// NTSTATUS __stdcall ZwQuerySystemInformation(SYSTEM_INFORMATION_CLASS SystemInformationClass, PVOID SystemInformation, ULONG SystemInformationLength, PULONG ReturnLength);
// void *__cdecl memcpy(void *, const void *, size_t);
// void *__cdecl memset(void *, int, size_t);
// int _SEH_epilog(void); weak
int nullsub_1(); // weak
int nullsub_2(); // weak
int sub_124FE(); // weak
int nullsub_3(); // weak
// KIRQL __fastcall KfAcquireSpinLock(PKSPIN_LOCK SpinLock);
// KIRQL __stdcall KeGetCurrentIrql();
// void __fastcall KfReleaseSpinLock(PKSPIN_LOCK SpinLock, KIRQL NewIrql);
// NTSTATUS __stdcall ZwReadFile(HANDLE FileHandle, HANDLE Event, PIO_APC_ROUTINE ApcRoutine, PVOID ApcContext, PIO_STATUS_BLOCK IoStatusBlock, PVOID Buffer, ULONG Length, PLARGE_INTEGER ByteOffset, PULONG Key);
// NTSTATUS __stdcall ZwClose(HANDLE Handle);
// NTSTATUS __stdcall ZwOpenFile(PHANDLE FileHandle, ACCESS_MASK DesiredAccess, POBJECT_ATTRIBUTES ObjectAttributes, PIO_STATUS_BLOCK IoStatusBlock, ULONG ShareAccess, ULONG OpenOptions);
// NTSTATUS __stdcall ZwQueryInformationFile(HANDLE FileHandle, PIO_STATUS_BLOCK IoStatusBlock, PVOID FileInformation, ULONG Length, FILE_INFORMATION_CLASS FileInformationClass);
// BOOLEAN __stdcall PsGetVersion(PULONG MajorVersion, PULONG MinorVersion, PULONG BuildNumber, PUNICODE_STRING CSDVersion);
// int __cdecl stricmp(const char *, const char ;
// NTSTATUS __stdcall PsSetLoadImageNotifyRoutine(PLOAD_IMAGE_NOTIFY_ROUTINE NotifyRoutine);
// PVOID __stdcall ExAllocatePool(POOL_TYPE PoolType, SIZE_T NumberOfBytes);
// void __fastcall IofCompleteRequest(PIRP Irp, CCHAR PriorityBoost);
// NTSTATUS __stdcall IoCreateDevice(PDRIVER_OBJECT DriverObject, ULONG DeviceExtensionSize, PUNICODE_STRING DeviceName, ULONG DeviceType, ULONG DeviceCharacteristics, BOOLEAN Exclusive, PDEVICE_OBJECT eviceObject);
// BOOLEAN __stdcall RtlDeleteElementGenericTable(PRTL_GENERIC_TABLE Table, PVOID Buffer);
// PKTHREAD __stdcall KeGetCurrentThread();
// PVOID __stdcall RtlLookupElementGenericTable(PRTL_GENERIC_TABLE Table, PVOID Buffer);
// void __stdcall RtlInitializeGenericTable(PRTL_GENERIC_TABLE Table, PRTL_GENERIC_COMPARE_ROUTINE CompareRoutine, PRTL_GENERIC_ALLOCATE_ROUTINE AllocateRoutine, PRTL_GENERIC_FREE_ROUTINE FreeRoutine, PVOID TableContext);
// PVOID __stdcall RtlInsertElementGenericTable(PRTL_GENERIC_TABLE Table, PVOID Buffer, CLONG BufferSize, PBOOLEAN NewElement);
// WCHAR __stdcall RtlUpcaseUnicodeChar(WCHAR SourceCharacter);
// NTSTATUS __stdcall ZwAllocateVirtualMemory(HANDLE ProcessHandle, PVOID *BaseAddress, ULONG ZeroBits, PULONG AllocationSize, ULONG AllocationType, ULONG Protect);
// void __stdcall RtlInitUnicodeString(PUNICODE_STRING DestinationString, PCWSTR SourceString);
// void __stdcall IoRegisterDriverReinitialization(PDRIVER_OBJECT DriverObject, PDRIVER_REINITIALIZE DriverReinitializationRoutine, PVOID Context);
// void __stdcall ExFreePoolWithTag(PVOID P, ULONG Tag);
// void __stdcall KeInitializeMutex(PRKMUTEX Mutex, ULONG Level);
// LONG __stdcall KeReleaseMutex(PRKMUTEX Mutex, BOOLEAN Wait);
// NTSTATUS __stdcall KeWaitForSingleObject(PVOID Object, KWAIT_REASON WaitReason, KPROCESSOR_MODE WaitMode, BOOLEAN Alertable, PLARGE_INTEGER Timeout);
// NTSTATUS __stdcall ZwQueryValueKey(HANDLE KeyHandle, PUNICODE_STRING ValueName, KEY_VALUE_INFORMATION_CLASS KeyValueInformationClass, PVOID KeyValueInformation, ULONG Length, PULONG ResultLength);
// NTSTATUS __stdcall ZwOpenKey(PHANDLE KeyHandle, ACCESS_MASK DesiredAccess, POBJECT_ATTRIBUTES ObjectAttributes);
// int __stdcall KeUnstackDetachProcess(_DWORD); weak
// int __stdcall KeStackAttachProcess(_DWORD, _DWORD); weak
// NTSTATUS __stdcall ZwQueryInformationProcess(HANDLE ProcessHandle, PROCESSINFOCLASS ProcessInformationClass, PVOID ProcessInformation, ULONG ProcessInformationLength, PULONG ReturnLength);
// int __stdcall ObOpenObjectByPointer(_DWORD, _DWORD, _DWORD, _DWORD, _DWORD, _DWORD, _DWORD); weak
// int __stdcall PsLookupProcessByProcessId(_DWORD, _DWORD); weak
// LONG_PTR __fastcall ObfDereferenceObject(PVOID Object);
// signed int __usercall sub_12A24<eax>(int a1<esi>);
signed int __cdecl sub_12A95(int a1);
// bool __usercall sub_12D37<eax>(int a1<eax>, int a2);
int __thiscall sub_12D71(void *this);
// signed int __usercall sub_13343<eax>(int a1<eax>, unsigned int a2);
// int __usercall sub_133BF<eax>(int a1<eax>, int a2, int a3);
// int __usercall sub_13409<eax>(int a1<eax>, int a2, int a3, int a4);
// int __usercall sub_1356E<eax>(unsigned int *a1<eax>, int a2<ebx>, int a3<edi>, int a4, int a5, int a6);
int __thiscall sub_1369C(void *this);
signed int __cdecl sub_136F8(int a1, int a2, int a3);
signed int __cdecl sub_138BE(int a1, unsigned int a2);
bool __cdecl sub_138DB(int a1, unsigned int a2, int a3, int a4);
int __cdecl sub_1392E(int a1);
// signed int __usercall sub_13A4B<eax>(unsigned int a1<eax>, int a2, int a3, unsigned __int16 a4);
// signed int __usercall sub_13B3A<eax>(int a1<eax>, unsigned int a2<ebx>);
// int __usercall sub_13BF1<eax>(unsigned int a1<eax>, int a2<ecx>, int a3, int a4, int a5);
// signed int __usercall sub_13C66<eax>(int a1<eax>, int a2<edx>, int a3<ecx>, unsigned int a4);
int __cdecl sub_13C92(int a1, char a2, int a3);
// int __usercall sub_13CC0<eax>(int a1<eax>, int a2<edx>);
// signed int __usercall sub_13D8E<eax>(int a1<eax>, int a2, int a3, unsigned int a4, int (__cdecl *a5)(_DWORD, _DWORD, _DWORD));

//----- (00010300) --------------------------------------------------------
char __cdecl sub_10300()
{
LSA_UNICODE_STRING DestinationString; // [sp+8h] [bp-18h]@1
char v2; // [sp+10h] [bp-10h]@1
HANDLE Handle; // [sp+14h] [bp-Ch]@2
int v4; // [sp+18h] [bp-8h]@1
char v5; // [sp+1Fh] [bp-1h]@1

RtlInitUnicodeString(&DestinationString, L"\\SystemRoot\\System32\\hal.dll");
v4 = 0;
sub_105E4(&DestinationString, (int)&v4, (int)&v2);
v5 = v4 == 0;
if ( v2 )
{
v2 = 0;
ZwClose(Handle);
}
return v5;
}

//----- (0001034C) --------------------------------------------------------
void __stdcall DriverReinitializationRoutine(PDRIVER_OBJECT DriverObject, int a2, unsigned int a3)
{
if ( !KeGetCurrentIrql() )
{
if ( a3 <= 0x65 )
{
if ( !sub_10542() )
{
if ( sub_10300() )
sub_10A3A();
else
IoRegisterDriverReinitialization(DriverObject, DriverReinitializationRoutine, 0);
}
}
}
}

//----- (000103AA) --------------------------------------------------------
NTSTATUS __stdcall DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath)
{
signed int v2; // eax@2
LSA_UNICODE_STRING DestinationString; // [sp+Ch] [bp-24h]@11
unsigned int i; // [sp+14h] [bp-1Ch]@3
CPPEH_RECORD ms_exc; // [sp+18h] [bp-18h]@1

ms_exc.disabled = 0;
dword_14624 = 128;
dword_1461C = (int)ExAllocatePool(0, 0x200u);
if ( dword_1461C )
{
byte_14628 = 1;
for ( i = (unsigned int)&unk_14380; i < (unsigned int)&unk_14384; i += 4 )
{
if ( *(_DWORD i )
(*(void (**)(void))i)();
}
v2 = 0;
}
else
{
v2 = -1073741823;
}
if ( !v2 )
{
if ( !sub_109B0((int)RegistryPath) )
{
RtlInitUnicodeString(&DestinationString, &SourceString);
if ( !IoCreateDevice(DriverObject, 0, &DestinationString, 0x22u, 0x100u, 0, (PDEVICE_OBJECT &RegistryPath) )
{
DriverObject->MajorFunction[0] = (PDRIVER_DISPATCH)sub_10BA2;
DriverObject->MajorFunction[2] = (PDRIVER_DISPATCH)sub_10BA2;
DriverObject->MajorFunction[14] = (PDRIVER_DISPATCH)sub_10BA2;
RegistryPath[3].Buffer = (PWSTR)((unsigned int)RegistryPath[3].Buffer & 0xFFFFFF7F);
IoRegisterDriverReinitialization(DriverObject, (PDRIVER_REINITIALIZE)DriverReinitializationRoutine, 0);
}
}
}
return 0;
}
// 10BA2: using guessed type int __stdcall sub_10BA2(int, int);
// 1461C: using guessed type int dword_1461C;
// 14624: using guessed type int dword_14624;
// 14628: using guessed type char byte_14628;

//----- (0001048A) --------------------------------------------------------
int __stdcall sub_1048A(int a1)
{
int v1; // edi@5
int result; // eax@7
int (*v3)(void); // edi@11
int v4; // [sp+Ch] [bp-128h]@6
__int16 v5; // [sp+120h] [bp-14h]@9
int v6; // [sp+130h] [bp-4h]@3

*(_BYTE a1 = 1;
if ( !KeGetCurrentIrql() )
{
sub_1056C((int)&v6);
if ( sub_10886(0) || sub_10886(1) )
return 0;
v1 = v6;
if ( sub_10886(2) )
{
memset(&v4, 255, 0x11Cu);
v4 = 284;
if ( !*(_DWORD v1 )
return -1073741823;
result = (*(int (__stdcall **)(int )v1)(&v4);
if ( result )
return result;
if ( !v5 )
return *(_DWORD (v1 + 4) != 0 ? 0xC0000001 : 0;
}
v3 = *(int (**)(void))(v1 + 4);
if ( v3 )
{
if ( (unsigned __int8)v3() )
*(_BYTE a1 = 0;
return 0;
}
return -1073741823;
}
*(_BYTE a1 = 0;
return 0;
}

//----- (00010542) --------------------------------------------------------
int __cdecl sub_10542()
{
int result; // eax@1
char v1; // [sp+7h] [bp-1h]@1

v1 = 0;
result = sub_1048A((int)&v1);
if ( !result )
result = (v1 != 0 ? 0x3FFFFFFF : 0) - 1073741823;
return result;
}

//----- (0001056C) --------------------------------------------------------
int __usercall sub_1056C<eax>(int a1<esi>)
{
int v1; // ecx@2

*(_DWORD a1 = 0;
if ( !(dword_146A4 & 1) )
{
dword_146A4 |= 1u;
sub_107E8();
sub_107A2(v1, (int)nullsub_1);
}
byte_14614 = 0;
*(_DWORD a1 = &dword_14694;
return a1;
}
// 124FA: using guessed type int nullsub_1();
// 14614: using guessed type char byte_14614;
// 14694: using guessed type int dword_14694;
// 146A4: using guessed type int dword_146A4;

//----- (000105A0) --------------------------------------------------------
int __userpurge sub_105A0<eax>(int a1<ebx>, SIZE_T a2<edi>, int a3<esi>, const void *a4)
{
PVOID v4; // eax@1
char v5; // zf@1

v4 = ExAllocatePool(0, a2);
v5 = *(_DWORD a1 == 0;
*(_DWORD a3 = v4;
*(_DWORD (a3 + 4) = a2;
*(_DWORD (a3 + 8) = v4;
*(_DWORD (a3 + 12) = a2;
if ( v5 )
{
if ( *(_DWORD a3 )
{
if ( a4 )
memcpy(*(void **)a3, a4, a2);
}
else
{
*(_DWORD a1 = -1073741823;
}
}
return a3;
}

//----- (000105E4) --------------------------------------------------------
int __usercall sub_105E4<eax>(LSA_UNICODE_STRING *a1<ecx>, int a2<edi>, int a3<esi>)
{
char v3; // zf@1
NTSTATUS v4; // eax@2
OBJECT_ATTRIBUTES ObjectAttributes; // [sp+8h] [bp-20h]@2
struct _IO_STATUS_BLOCK IoStatusBlock; // [sp+20h] [bp-8h]@2

v3 = *(_DWORD a2 == 0;
*(_BYTE a3 = 0;
*(_DWORD (a3 + 4) = 0;
if ( v3 )
{
ObjectAttributes.ObjectName = a1;
ObjectAttributes.Length = 24;
ObjectAttributes.RootDirectory = 0;
ObjectAttributes.Attributes = 576;
ObjectAttributes.SecurityDescriptor = 0;
ObjectAttributes.SecurityQualityOfService = 0;
v4 = ZwOpenFile((PHANDLE)(a3 + 4), 0x80100000u, &ObjectAttributes, &IoStatusBlock, 1u, 0x60u);
*(_DWORD a2 = v4;
*(_BYTE a3 = v4 == 0;
}
return a3;
}

//----- (00010638) --------------------------------------------------------
ULONG __thiscall sub_10638(LSA_UNICODE_STRING *this, ULONG a2, int a3)
{
char v3; // bl@1
ULONG result; // eax@4
HANDLE v5; // ecx@6
ULONG v6; // edi@6
ULONG v7; // esi@6
NTSTATUS v8; // eax@7
int v9; // eax@17
int v10; // eax@18
void **v11; // eax@21
void *v12; // eax@22
char FileInformation; // [sp+10h] [bp-28h]@7
ULONG v14; // [sp+18h] [bp-20h]@7
void *v15; // [sp+1Ch] [bp-1Ch]@7
ULONG Length; // [sp+28h] [bp-10h]@1
HANDLE Handle; // [sp+2Ch] [bp-Ch]@3
struct _IO_STATUS_BLOCK IoStatusBlock; // [sp+30h] [bp-8h]@1

v3 = 0;
IoStatusBlock.Information = 0;
sub_105E4(this, (int)&IoStatusBlock.Information, (int)&Length);
if ( IoStatusBlock.Information )
goto LABEL_2;
if ( (_BYTE)Length )
{
v8 = ZwQueryInformationFile(Handle, &IoStatusBlock, &FileInformation, 0x18u, FileStandardInformation);
v6 = v14;
v5 = v15;
v7 = v8;
}
else
{
v5 = Handle;
v6 = Length;
v7 = -1073741823;
}
IoStatusBlock.Information = v7;
if ( v7 )
goto LABEL_9;
if ( v5 || v6 > a2 )
goto LABEL_31;
v9 = (int)ExAllocatePool(0, 0x10u);
if ( v9 )
v10 = sub_105A0((int)&IoStatusBlock.Information, v6, v9, 0);
else
v10 = 0;
sub_1076E(a3, (PVOID v10);
v3 = 0;
if ( IoStatusBlock.Information )
{
LABEL_2:
if ( (_BYTE)Length != v3 )
{
LOBYTE(Length) = v3;
ZwClose(Handle);
}
return IoStatusBlock.Information;
}
v11 = *(void ***)(a3 + 4);
if ( !v11 )
goto LABEL_31;
v12 = *v11;
if ( !(_BYTE)Length )
return -1073741823;
v7 = ZwReadFile(Handle, 0, 0, 0, &IoStatusBlock, v12, v6, 0, 0);
if ( v7 )
{
LABEL_9:
if ( (_BYTE)Length != v3 )
{
LOBYTE(Length) = v3;
ZwClose(Handle);
}
return v7;
}
if ( IoStatusBlock.Information != v6 )
{
LABEL_31:
if ( (_BYTE)Length != v3 )
{
LOBYTE(Length) = v3;
ZwClose(Handle);
}
result = -1073741823;
}
else
{
if ( (_BYTE)Length )
{
LOBYTE(Length) = 0;
ZwClose(Handle);
}
result = 0;
}
return result;
}

//----- (0001076E) --------------------------------------------------------
void __userpurge sub_1076E(int a1<ebx>, PVOID *a2)
{
PVOID *v2; // esi@1

v2 = *(PVOID **)(a1 + 4);
if ( a2 != v2 )
{
if ( v2 )
{
if ( *v2 )
ExFreePoolWithTag(*v2, 0);
ExFreePoolWithTag(v2, 0);
}
*(_DWORD (a1 + 4) = a2;
}
}

//----- (000107A2) --------------------------------------------------------
signed int __fastcall sub_107A2(int a1, int a2)
{
signed int result; // eax@5

if ( !byte_14628 )
goto LABEL_9;
if ( !dword_1461C )
goto LABEL_9;
if ( dword_14624 <= dword_14620 )
goto LABEL_9;
_ECX = &dword_14620;
_EAX = 1;
__asm { lock xadd [ecx], eax }
if ( dword_14624 > _EAX )
{
*(_DWORD (dword_1461C + 4 * _EAX) = a2;
result = 0;
}
else
{
LABEL_9:
result = 1;
}
return result;
}
// 1461C: using guessed type int dword_1461C;
// 14620: using guessed type int dword_14620;
// 14624: using guessed type int dword_14624;
// 14628: using guessed type char byte_14628;

//----- (000107E8) --------------------------------------------------------
int *__cdecl sub_107E8()
{
int v0; // eax@2
char v2; // [sp+4h] [bp-20h]@3

dword_14694 = 0;
dword_14698 = 0;
dword_1469C = 0;
dword_146A0 = 0;
if ( !sub_10886(0) )
{
v0 = sub_1098E();
if ( v0 )
{
if ( !sub_121E1((int)&v2, v0, 1) )
{
dword_14694 = sub_1236B((int)&v2, -899745608);
dword_14698 = sub_1236B((int)&v2, -1332885072);
dword_1469C = sub_1236B((int)&v2, -2007787012);
dword_146A0 = sub_1236B((int)&v2, 1516803388);
}
}
}
return &dword_14694;
}
// 14694: using guessed type int dword_14694;
// 14698: using guessed type int dword_14698;
// 1469C: using guessed type int dword_1469C;
// 146A0: using guessed type int dword_146A0;

//----- (00010886) --------------------------------------------------------
bool __stdcall sub_10886(int a1)
{
ULONG MinorVersion; // [sp+0h] [bp-8h]@1
ULONG MajorVersion; // [sp+4h] [bp-4h]@1

MajorVersion = 0;
MinorVersion = 0;
PsGetVersion(&MajorVersion, &MinorVersion, 0, 0);
return MajorVersion == 5 && a1 == MinorVersion;
}

//----- (000108BE) --------------------------------------------------------
int __stdcall sub_108BE(const char *a1)
{
ULONG v1; // edi@3
PVOID v2; // esi@6
int v4; // edi@17
PVOID v5; // [sp-8h] [bp-3Ch]@5
ULONG v6; // [sp-4h] [bp-38h]@5
PVOID P; // [sp+10h] [bp-24h]@3
int SystemInformation; // [sp+20h] [bp-14h]@1
char *v9; // [sp+24h] [bp-10h]@3
int v10; // [sp+28h] [bp-Ch]@13
ULONG SystemInformationLength; // [sp+2Ch] [bp-8h]@1

SystemInformationLength = 0;
SystemInformation = 0;
if ( ZwQuerySystemInformation(SystemModuleInformation, &SystemInformation, 0, &SystemInformationLength) != -1073741820
|| !SystemInformationLength )
return 0;
v9 = 0;
sub_105A0((int)&v9, SystemInformationLength, (int)&P, 0);
v1 = 0;
if ( v9 )
{
if ( P )
{
v6 = 0;
v5 = P;
LABEL_9:
ExFreePoolWithTag(v5, v6);
}
return 0;
}
v2 = P;
if ( ZwQuerySystemInformation(SystemModuleInformation, P, SystemInformationLength, (PULONG)&SystemInformation) )
{
if ( !v2 )
return 0;
LABEL_8:
v6 = v1;
v5 = v2;
goto LABEL_9;
}
if ( *(_DWORD v2 <= 0u )
goto LABEL_8;
v10 = 0;
v9 = (char v2 + 30;
while ( stricmp((const char v2 + v10 + *(_WORD v9 + 32, a1) )
{
v10 += 284;
v9 += 284;
++v1;
if ( v1 >= *(_DWORD v2 )
{
v1 = 0;
goto LABEL_8;
}
}
v4 = *((_DWORD v2 + 71 * v1 + 3);
ExFreePoolWithTag(v2, 0);
return v4;
}

//----- (0001098E) --------------------------------------------------------
int __cdecl sub_1098E()
{
int result; // eax@1

result = sub_108BE(dword_124C0);
if ( !result )
result = sub_108BE(dword_124D0);
return result;
}

//----- (000109B0) --------------------------------------------------------
signed int __usercall sub_109B0<eax>(int a1<edi>)
{
signed int result; // eax@8

if ( byte_14390 )
{
sub_11EC6(0, (int)&dword_14391, 0x278u);
byte_14390 = 0;
}
if ( !word_14395 )
{
if ( (unsigned int)*(_WORD a1 + 2 <= 0xC8 )
{
memset((void &word_14395, 0, 0xC8u);
memcpy((void &word_14395, *(const void **)(a1 + 4), *(_WORD a1);
}
}
if ( dword_14391 & 1 && InitSafeBootMode || dword_14391 & 2 && (_BYTE)KdDebuggerEnabled )
result = -1073741823;
else
result = 0;
return result;
}
// 125E4: using guessed type void *InitSafeBootMode;
// 14390: using guessed type char byte_14390;
// 14391: using guessed type int dword_14391;

//----- (00010A3A) --------------------------------------------------------
int __cdecl sub_10A3A()
{
int result; // eax@1
char v1; // [sp+8h] [bp-8h]@1
int v2; // [sp+Ch] [bp-4h]@1

v2 = 0;
sub_10A8A((int)&v1, &v2);
result = v2;
if ( !v2 )
{
sub_10AE2((int)&v2);
result = sub_10C22(v2);
if ( !result )
{
sub_10B36((int)&v1);
sub_1056C((int)&v1);
result = PsSetLoadImageNotifyRoutine((PLOAD_IMAGE_NOTIFY_ROUTINE)NotifyRoutine);
}
}
return result;
}

//----- (00010A8A) --------------------------------------------------------
int __usercall sub_10A8A<eax>(int a1<edi>, int *a2<esi>)
{
int v2; // eax@2
int v3; // ecx@4

*(_DWORD a1 = 0;
if ( !(dword_146B0 & 1) )
{
v2 = *a2;
dword_146B0 |= 1u;
dword_146AC = v2;
}
if ( !(dword_146B0 & 2) )
{
dword_146B0 |= 2u;
sub_11C14();
sub_107A2(v3, (int)nullsub_3);
}
if ( dword_146AC )
*a2 = dword_146AC;
else
*(_DWORD a1 = &dword_146A8;
byte_14615 = 0;
return a1;
}
// 12508: using guessed type int nullsub_3();
// 14615: using guessed type char byte_14615;
// 146A8: using guessed type int dword_146A8;
// 146AC: using guessed type int dword_146AC;
// 146B0: using guessed type int dword_146B0;

//----- (00010AE2) --------------------------------------------------------
int __usercall sub_10AE2<eax>(int a1<esi>)
{
int v1; // ecx@2

*(_DWORD a1 = 0;
if ( !(dword_14690 & 1) )
{
dword_14668 = 0;
dword_14690 |= 1u;
byte_14664 = 1;
memset(&Mutex, 0, sizeof(Mutex));
KeInitializeMutex(&Mutex, 0);
sub_107A2(v1, (int)sub_124FE);
}
byte_14616 = 0;
*(_DWORD a1 = &byte_14664;
return a1;
}
// 124FE: using guessed type int sub_124FE();
// 14616: using guessed type char byte_14616;
// 14664: using guessed type char byte_14664;
// 14668: using guessed type int dword_14668;
// 14690: using guessed type int dword_14690;

//----- (00010B36) --------------------------------------------------------
int __usercall sub_10B36<eax>(int a1<esi>)
{
int v1; // ecx@2

*(_DWORD a1 = 0;
if ( !(dword_1468C & 1) )
{
dword_1468C |= 1u;
sub_10FE6();
sub_107A2(v1, (int)nullsub_2);
}
byte_14617 = 0;
*(_DWORD a1 = &Table;
return a1;
}
// 124FC: using guessed type int nullsub_2();
// 14617: using guessed type char byte_14617;
// 1468C: using guessed type int dword_1468C;

//----- (00010B68) --------------------------------------------------------
int __thiscall sub_10B68(int this)
{
int result; // eax@3
int v2; // [sp+0h] [bp-4h]@1

v2 = this;
if ( *(_DWORD (*(_DWORD (this + 96) + 12) == 2242560 )
{
result = sub_11CCC(this);
}
else
{
if ( *(_DWORD (*(_DWORD (this + 96) + 12) == 2242564 )
{
sub_10AE2((int)&v2);
result = sub_10C22(v2);
}
else
{
result = -1073741822;
}
}
return result;
}

//----- (00010BE8) --------------------------------------------------------
signed int __cdecl sub_10BE8()
{
return 1;
}

//----- (00010BEC) --------------------------------------------------------
int __userpurge sub_10BEC<eax>(int a1<ebp>, int a2, int a3)
{
int v3; // edi@1
int v4; // esi@1

*(_DWORD (a1 - 4) = -1;
v4 = *(_DWORD (a1 + 12);
v3 = *(_DWORD (a1 - 28);
if ( v3 != 259 )
{
if ( v3 )
*(_DWORD (v4 + 28) = 0;
*(_DWORD (v4 + 24) = v3;
IofCompleteRequest((PIRP)v4, 0);
}
return _SEH_epilog();
}
// 12463: using guessed type int _SEH_epilog(void);

//----- (00010C22) --------------------------------------------------------
signed int __usercall sub_10C22<eax>(int a1<eax>)
{
int v1; // edi@1
int v2; // eax@3
unsigned int v3; // esi@3
int v4; // ecx@3
signed int v6; // esi@6
int v7; // edi@9
struct _KMUTANT *v8; // [sp+10h] [bp-20h]@1
ULONG v9; // [sp+14h] [bp-1Ch]@1
LSA_UNICODE_STRING ValueName; // [sp+18h] [bp-18h]@1
LSA_UNICODE_STRING DestinationString; // [sp+20h] [bp-10h]@1
char v12; // [sp+28h] [bp-8h]@2

v1 = a1;
RtlInitUnicodeString(&DestinationString, &word_14395);
RtlInitUnicodeString(&ValueName, &word_1445D);
v8 = (struct _KMUTANT (v1 + 8);
KeWaitForSingleObject((PVOID)(v1 + 8), 0, 0, 0, 0);
v9 = sub_11D62(&DestinationString, &ValueName, v1);
if ( v9 )
{
RtlInitUnicodeString((PUNICODE_STRING)&v12, &word_14471);
v9 = sub_10638((LSA_UNICODE_STRING &v12, dword_14539, v1);
if ( v9 )
{
LABEL_6:
v6 = -1073741823;
goto LABEL_7;
}
}
v2 = *(_DWORD (v1 + 4);
v3 = *(_DWORD (v2 + 4);
sub_11EC6(dword_1453D, *(_DWORD v2, v3);
if ( sub_11D46(v4, v3) )
{
KeReleaseMutex(v8, 0);
return -1073741823;
}
v6 = v9;
if ( !v9 )
{
v7 = *(_DWORD (v1 + 4);
if ( v7 && *(_DWORD (v7 + 4) > 0u )
{
v6 = 0;
goto LABEL_7;
}
goto LABEL_6;
}
LABEL_7:
KeReleaseMutex(v8, 0);
return v6;
}
// 14539: using guessed type int dword_14539;
// 1453D: using guessed type int dword_1453D;

//----- (00010CFE) --------------------------------------------------------
signed int __stdcall sub_10CFE(int a1, int a2)
{
int v2; // eax@1
int v3; // edi@1
int v4; // esi@1
int v5; // eax@2
signed int v6; // edi@5
int v8; // [sp+10h] [bp-4h]@1

v3 = a1;
v4 = 0;
v8 = 0;
KeWaitForSingleObject((PVOID)(a1 + 8), 0, 0, 0, 0);
v2 = (int)ExAllocatePool(0, 0x10u);
if ( v2 )
{
v5 = sub_105A0((int)&v8, *(_DWORD (*(_DWORD (a1 + 4) + 4), v2, **(const void ***)(a1 + 4));
v3 = a1;
v4 = 0;
}
else
{
v5 = 0;
}
sub_1076E(a2, (PVOID v5);
if ( v8 == v4 )
{
if ( *(_DWORD (v3 + 4) == v4 )
v6 = -1073741823;
else
v6 = 0;
}
else
{
v6 = v8;
}
KeReleaseMutex((PRKMUTEX)(a1 + 8), v4);
return v6;
}

//----- (00010D7E) --------------------------------------------------------
void __usercall sub_10D7E(int a1<eax>)
{
PVOID *v1; // edi@2

if ( *(_BYTE a1 )
{
v1 = *(PVOID **)(a1 + 4);
*(_BYTE a1 = 0;
if ( v1 )
{
if ( *v1 )
ExFreePoolWithTag(*v1, 0);
ExFreePoolWithTag(v1, 0);
}
}
}

//----- (00010DA8) --------------------------------------------------------
int __usercall sub_10DA8<eax>(int a1<ecx>, int a2<edi>, int a3<esi>)
{
int v4; // eax@1
int v5; // [sp+0h] [bp-4h]@1

v5 = a1;
sub_10FC4(a3, (int)&v5);
*(_DWORD a2 = *(_DWORD (a3 + 8) + *(_DWORD a3;
v4 = v5;
*(_DWORD (a2 + 4) = v5;
*(_DWORD (a3 + 8) += v4;
return a3;
}

//----- (00010DCC) --------------------------------------------------------
void __stdcall sub_10DCC(int a1, HANDLE Handle, int a3)
{
int v3; // ecx@9
int v4; // esi@9
int v5; // ebx@12
int v6; // ecx@12
int v7; // eax@14
int i; // [sp+10h] [bp-50h]@4
unsigned int v9; // [sp+14h] [bp-4Ch]@9
RTL_GENERIC_TABLE *v10; // [sp+18h] [bp-48h]@8
int v11; // [sp+1Ch] [bp-44h]@8
int v12; // [sp+20h] [bp-40h]@9
char v13; // [sp+24h] [bp-3Ch]@8
int v14; // [sp+28h] [bp-38h]@8
int v15; // [sp+2Ch] [bp-34h]@9
int v16; // [sp+30h] [bp-30h]@9
int v17; // [sp+34h] [bp-2Ch]@11
int v18; // [sp+38h] [bp-28h]@11
int v19; // [sp+3Ch] [bp-24h]@4
char v20; // [sp+40h] [bp-20h]@7
WCHAR *v21; // [sp+44h] [bp-1Ch]@11
char v22; // [sp+4Ch] [bp-14h]@14
int v23; // [sp+54h] [bp-Ch]@9
unsigned int v24; // [sp+58h] [bp-8h]@9
int v25; // [sp+5Ch] [bp-4h]@9

if ( sub_117A8(L"KERNEL32.DLL", a1) )
{
sub_1174A((int)Handle, a3);
}
else
{
if ( !sub_10542() )
{
i = 0;
sub_11F42((int)&v19, (int)&i, Handle);
if ( !i )
{
if ( v19 == *(_DWORD (a3 + 4) )
{
if ( !(dword_14391 & 4) || !v20 )
{
sub_10B36((int)&v10);
sub_11066((int)Handle, v10);
v13 = 1;
v14 = 0;
sub_10AE2((int)&v11);
if ( !sub_10CFE(v11, (int)&v13) )
{
v3 = *(_DWORD v14;
v24 = *(_DWORD (v14 + 4);
v23 = v3;
v25 = 0;
v15 = 0;
v16 = 0;
sub_10FC4((int)&v23, (int)&v12);
sub_10DA8(v3, (int)&v15, (int)&v23);
sub_10FC4((int)&v23, (int)&v9);
v4 = v25;
if ( v25 <= v24 )
{
if ( !v12 )
{
v21 = 0;
v17 = 0;
v18 = 0;
for ( i = 0; i < v9; ++i )
{
v5 = v4 + v23;
v25 = v4 + 16;
v12 = v4 + v23;
sub_10DA8(v3, (int)&v21, (int)&v23);
sub_10DA8(v6, (int)&v17, (int)&v23);
v4 = v25;
if ( v25 > v24 )
break;
if ( sub_117A8(v21, a1) )
{
v7 = sub_111B4((int)&v15, (int)&v22, *(_DWORD (v5 + 12));
sub_11522((int)Handle, a3, v12, (int)&v17, v7);
}
}
}
}
}
sub_10D7E((int)&v13);
}
}
}
}
}
}
// 124E0: using guessed type wchar_t aKernel32_dll[13];
// 14391: using guessed type int dword_14391;

//----- (00010F80) --------------------------------------------------------
void __stdcall NotifyRoutine(int a1, HANDLE Handle, int a3)
{
if ( KeGetCurrentIrql() <= 1u )
{
if ( Handle )
sub_10DCC(a1, Handle, a3);
}
}

//----- (00010FC4) --------------------------------------------------------
int __userpurge sub_10FC4<eax>(int result<eax>, int a2)
{
int v2; // ecx@1

v2 = *(_DWORD (result + 8);
if ( (unsigned int)(v2 + 4) <= *(_DWORD (result + 4) )
*(_DWORD a2 = *(_DWORD (v2 + *(_DWORD result);
*(_DWORD (result + 8) = v2 + 4;
return result;
}

//----- (00010FE6) --------------------------------------------------------
RTL_GENERIC_TABLE *__cdecl sub_10FE6()
{
memset(&Table, 0, sizeof(Table));
byte_14658 = -1;
dword_14654 = 0;
dword_1465C = 0;
dword_14660 = 0;
RtlInitializeGenericTable(
&Table,
(PRTL_GENERIC_COMPARE_ROUTINE)CompareRoutine,
(PRTL_GENERIC_ALLOCATE_ROUTINE)AllocateRoutine,
(PRTL_GENERIC_FREE_ROUTINE)FreeRoutine,
0);
return &Table;
}
// 14654: using guessed type int dword_14654;
// 14658: using guessed type char byte_14658;
// 1465C: using guessed type int dword_1465C;
// 14660: using guessed type int dword_14660;

//----- (00011028) --------------------------------------------------------
PVOID __usercall sub_11028<eax>(int a1<eax>, RTL_GENERIC_TABLE *a2<edi>)
{
PKSPIN_LOCK v2; // ecx@1
PVOID v3; // esi@1
PVOID v4; // eax@1
char v5; // zf@1
KIRQL v6; // dl@2
int Buffer; // [sp+8h] [bp-18h]@1
PKSPIN_LOCK SpinLock; // [sp+1Ch] [bp-4h]@1

quote:

Op zaterdag 18 februari 2012 16:05 schreef J0kkebr0k het volgende:
Uhm... mijn post van vannacht sloeg idd helemaal nergens op en was nogal kansloos! Laten we het er op houden dat ik net terug uit de kroeg was en straalbezopen achter FOK ben gaan zitten

quote:

Op zaterdag 18 februari 2012 16:05 schreef J0kkebr0k het volgende:
Uhm... mijn post van vannacht sloeg idd helemaal nergens op en was nogal kansloos! Laten we het er op houden dat ik net terug uit de kroeg was en straalbezopen achter FOK ben gaan zitten

Ooit weleens een aanvarinkje met ChunLingSoo gehad, denk dat ik dat even wilde laten weten ofzo

Excuses boys!

quote:

Op zaterdag 18 februari 2012 17:06 schreef Bankfurt het volgende:

[..]

Er is een volkswijsheid die zegt dat dronken mensen de waarheid vertellen ....

quote:

Op zaterdag 18 februari 2012 16:05 schreef J0kkebr0k het volgende:
Uhm... mijn post van vannacht sloeg idd helemaal nergens op en was nogal kansloos! Laten we het er op houden dat ik net terug uit de kroeg was en straalbezopen achter FOK ben gaan zitten

Ooit weleens een aanvarinkje met ChunLingSoo gehad, denk dat ik dat even wilde laten weten ofzo

Excuses boys!

quote:

Op zaterdag 18 februari 2012 17:35 schreef picodealion het volgende:

[..]

Dit vind ik netjes .

quote:

Op dinsdag 21 februari 2012 11:17 schreef _Led_ het volgende:
Geen idee of ie al gepost was, maar een mooie samenvatting die iedereen kan begrijpen :

Stuxnet

quote:

Duqu-virus geschreven in onbekende programmeertaal
AMSTERDAM – Het Duqu-virus is geschreven in een onbekende programmeertaal wat het nog moeilijker maakt de software te doorgronden.

Dat schrijft Kaspersky op basis van onderzoek waar het bedrijf aan meewerkt.
Het virus dook eind vorig jaar op. In Iran werden 30.000 computers besmet met Stuxnet. Duqu is een ander virus dat op Stuxnet gebaseerd is en vooral bedoeld lijkt te zijn voor spionage en het vergaren van informatie over computersystemen zodat toekomstige cyberaanvallen gemakkelijker uit te voeren zijn.

Na onderzoek blijkt nu dat het virus in een nog onbekende programmeertaal geschreven is. Het gaat dan vooral om delen die het mogelijk maken om het virus opdrachten te geven als het in een systeem geïnfiltreerd is.

De rest van het programma is geschreven in C++, maar niet de belangrijkste delen. “Het is iets dat we nog nooit eerder gezien hebben”, aldus onderzoekers van Kaspersky. Volgens hen wijst de geheime programmeertaal erop dat Duqu gemaakt is door een nationale regering en niet zomaar een paar hackers.

quote:

Op vrijdag 9 maart 2012 12:46 schreef Gray het volgende:

quote:

'Duqu-trojan deels geschreven in onbekende programmeertaal'
Door Dimitri Reijerman, donderdag 8 maart 2012 19:15, views: 40.759

Kaspersky Lab heeft na een analyse van de Duqu-trojan een onderdeel gevonden dat in een tot nu toe onbekende programmeertaal zou zijn geschreven. De Russische beveiligingsfirma vraagt daarom programmeurs om hulp.

De Duqu-trojan, dat is gespecialiseerd in het aanbrengen van een achterdeurtje op besmette systemen, is grotendeels identiek aan de code van Stuxnet, de malware die poogde scada-systemen van het Iraanse kernprogramma te saboteren. Na een grondige analyse van de code concludeert Kaspersky Lab dat een onderdeel dat contact maakt met een command and control-server, oftewel de payload-dll, in een onbekende programmeertaal is geschreven, terwijl de overige onderdelen bestaan uit C++-code en er gebruik is gemaakt van de Microsoft Visual C++ 2008-compiler. Kasperky sluit uit dat het 'mysterieuze' Duqu-onderdeel is geschreven in Python, Java, Objective C, Ada of Lua.

Volgens de Russische malware-onderzoekers is het mogelijk dat de Duqu-programmeurs een eigen framework hebben gebouwd om zelfgeschreven C-code met een eigen compiler te compileren of dat er een tot nu toe onbekende taal is ontwikkeld. Het 'Duqu-framework' blijkt bovendien zeer veelzijdig in zijn mogelijkheden. Zo kan de betreffende module op diverse manieren contact maken met de c&c-servers, onder andere via http, proxy servers en netwerk-sockets. Ook kan de module http-requests van de server afhandelen en is het in staat om buitgemaakte informatie door te sturen of nieuwe malware-code te injecteren op andere met Duqu besmette systemen binnen een netwerk.

Met de aanwijzingen dat de bouwers van de Duqu-malware een eigen programmeertaal hebben ontwikkeld, lijkt het niet ondenkbaar dat de betreffende programmeurs niet alleen zeer vakkundig waren, maar vermoedelijk ook over ruime financiële middelen beschikten. Verder sluit Kaspersky niet uit dat de c&c-module door een ander team is geschreven en pas later aan de overige Duqu-onderdelen is toegevoegd. Om het 'mysterie' rondom de c&c-module op te lossen, vraagt Kaspersky Lab om hulp van de ontwikkelgemeenschap.
_bron

quote:

The Framework
Features

The code that implements the Duqu Framework has several distinctive properties:

Everything is wrapped into objects
Function table is placed directly into the class instance and can be modified after construction
There is no distinction between utility classes (linked lists, hashes) and user-written code
Objects communicate using method calls, deferred execution queues and event-driven callbacks
There are no references to run-time library functions, native Windows API is used instead

Objects

All objects are instances of some class, we identified 60 classes. Each object is constructed with a “constructor” function that allocates memory, fills in the function table and initializes members.

quote:

Conclusions

The Duqu Framework appears to have been written in an unknown programming language.
Unlike the rest of the Duqu body, it's not C++ and it's not compiled with Microsoft's Visual C++ 2008.
The highly event driven architecture points to code which was designed to be used in pretty much any kind of conditions, including asynchronous commutations.
Given the size of the Duqu project, it is possible that another team was responsible for the framework than the team which created the drivers and wrote the system infection and exploits.
The mysterious programming language is definitively NOT C++, Objective C, Java, Python, Ada, Lua and many other languages we have checked.
Compared to Stuxnet (entirely written in MSVC++), this is one of the defining particularities of the Duqu framework.

quote:

Re: That code looks familiar

It's easier to figure this out if you consider vendor sourcing. The work was probably done by a government. And, whether the software was sourced through a US agency or whether a US agency itself was the creator, the net result is the same: you're looking for a major GSA-contracted firm who A) has clearance, B) has a compiler team, C) has a track record of providing similar product to the US government, and D) has a compiler codebase that looks kind of unfamiliar and not mainstream.

The likely suspects fitting that set of criteria are IBM, Microsoft, SAS and SAIC. All the others (remnant AT T, HP, remnant SGI... who am I forgetting?) incorporate a considerable amount of fairly recognizable shared compiler code in their offerings. Since you've disqualified Microsoft, my bet is on IBM.

I don't think it's SAS, because their compiler codebase is ancient. I don't think it's SAIC, because for them this would be a fairly difficult project. Three reasons why I think IBM.

First is that IBM has a library of bizarro options to select from. There's an internal HLASM-to-C frontend. There's all the CSet descendants. They've got research versions of damn near everything. (I'd try getting ahold of the ia32 version of CSet - probably hard to come by, but out there). They've also got a Windows source license, and if you were going to write a virus, that's always handy.

Second is that IBM has a history of doing projects like this. If there was a federal bid, they almost certainly would have been a bidder.

Third is that the project could have been run out of IBM Haifa. A number of the old IBM AV team probably either were there or ended up there, so it wouldn't be too far out of their wheelhouse. And if you wanted to build a state-sponsored virus, you'd almost certainly want to build it in a country who already has near-active hostilities with the intended target for the virus such that those acts of aggression don't become de facto acts of war for you.

If you want to dig into that, have someone from IBM wander through the employee-written and internal software libraries for all the preprocessor frontends for various languages and compiler backends that output to ia32. Probably none of that is inherently secret. I bet you'll find something that produces similar output.

quote:

Op zaterdag 10 maart 2012 00:53 schreef YuckFou het volgende:
F8ck me....ik had even tijd om verder te lezen bij http://www.securelist.com(...)u_Framework#page_top
en wat daar voorbij komt....

[..]

[ afbeelding ]

quote:

Event driven framework

.....
Dus toch een heus [BNW] thingy
Maar verderop worden veel programmeertalen voorgesteld en onderuit gehaald, zeker een topic om te blijven volgen op dat blog!!

quote:

Op vrijdag 9 maart 2012 13:34 schreef YuckFou het volgende:

[..]

Ik had t ook al gelezen op twaekers:

[..]

[ afbeelding ]

ChungLingSoo, werrrrk aan de winkel!

quote:

Op zaterdag 10 maart 2012 11:06 schreef ChungLingSoo het volgende:

'onbekende programmeertaal' is sowieso gelul. Als je een eigen low level vm hebt geschreven kan je daarbinnen doen wat je wil. Ziet er een beetje raar uit voor mensen die jouw vm niet kennen maar het maakt het zeker niet speciaal.

quote:

Mysterieuze programmeertaal Duqu blijkt 'C-dialect'

Een module van de Duqu-trojan die volgens Kasperky Lab in een onbekende programmeertaal was geschreven, zou gebaseerd zijn op een objectgeoriënteerd C-dialect. De module is gecompileerd met de Microsoft Visual Studio Compiler 2008.

Kaspersky Lab vroeg onlangs de hulp van programmeurs om te kunnen bepalen in welke programmeertaal een module van de Duqu-trojan was geschreven. Deze payload-module zorgt voor het contact met een command and control-server. Hoewel de overige onderdelen in C++ waren geschreven en met behulp van de Microsoft Visual C++ 2008-compiler gecompileerd waren, kon het Russische beveiligingsbedrijf niet achterhalen in welke taal de module was geschreven.

Inmiddels zegt Kaspersky Lab dat de programmertaal is geïdentificeerd dankzij de input van lezers. Volgens een aantal programmeurs zou de code geschreven zijn in 'OO C', een objectgeoriënteerd dialect van de C-programmeertaal. Ook zou de binary aanwijzingen bevatten dat de Microsoft Visual Studio Compiler 2008 zou zijn gebruikt voor het compileren van de betreffende Duqu-module.

Kaspersky Lab meldt dat het na diverse tests met de Visual Studio Compiler 2008 in combinatie met een aantal flags code heeft geproduceerd die vergelijkbaar is met de 'mysterieuze' Duqu-module. De extra parameters die werden gebruikt zouden compactere code opleveren.

Volgens de beveiligingsonderzoekers kan met de keuze voor het C-dialect gesteld worden dat de ontwikkelaars een old school-programmeermethode hebben gebruikt die niet vaak wordt toegepast door malware-schrijvers. De objectgeörienteerde benadering zou vooral binnen commerciële software gehanteerd worden. Ook de keuze voor C in plaats van het modernere C++ zou wijzen op programmeurs met een behoudende wijze van programmeren. Verder zou de keuze voor C als voordeel hebben dat de geschreven broncode van de malware ook relatief eenvoudig voor andere platformen gecompileerd kan worden, zodat malware die bedoeld is voor servers of mobiele-besturingssystemen snel opgeleverd kan worden.
_tweakers

quote:

Iranian oil ministry hit by cyber-attack

Iran's main oil export terminal is cut off from internet after apparent attack on website and communications systems

Iran's oil ministry has called a crisis meeting after its main website and internal communications system were hit by an apparent cyber-attack that forced authorities to cut off the country's oil export terminal from the internet.

Local news agencies reported on Monday that a virus had struck the computer and communication systems of Iran's main oil export facilities on Kharg Island as well as the internal network and the websites of its oil ministry and subsidiary organisations.

The semi-official Mehr news agency quoted ministry officials as saying an investigation was under way. "We are making plans to neutralise this cyber-attack," said the deputy oil minister in charge of civil defence, Hamdollah Mohammadnejad.

The Kharg Island oil terminal, which exports 80% of the country's daily 2.2m barrels, was hit by the virus, along with terminals on the islands of Gheshm and Kish.

Officials told Mehr that disconnecting the ministry from the global internet was a precautionary move to protect its main services and denied it was taken offline because of damage caused by the virus. Among services provided by the ministry's website are fuel cards, which millions of Iranians use on a daily basis to buy petrol for cars.

No individual or group has yet claimed responsibility for the attack and the motives behind it are still unknown, but other Iranian energy sectors have also been targeted by similar cyberstrikes in recent years.

In 2010 a computer worm called Stuxnet, which was believed to have been designed to sabotage the country's enrichment of uranium, hit many Iranian nuclear sites.

Unlike this time, officials initially denied nuclear facilities had been infected by Stuxnet but later admitted it had happened, claiming they had neutralised it before it inflicted any damage.

Iranian officials accuse the west, the US and Israel in particular, of being behind a covert campaign to stop Iran from advancing in its nuclear activities by using cyber-attacks and murdering its nuclear scientists, four of whom have been killed in the past two years.

Iran's response to the cyber-attacks has been to work on a countrywide network project, called national internet, whose primary aim is to protect Iranian military, banking and sensitive data from the outside world but also aims to be a substitute for the world wide web for ordinary users. The plan, which has not been launched yet, has drawn a great deal of criticism among Iranian web users.

An Iranian IT expert involved in Iran's national internet project, who spoke to the Guardian on condition of anonymity earlier this year, said: "Iran has fears of an outside cyber-attack like that of the Stuxnet, and is trying to protect its sensitive data from being accessible on the internet [by creating a secure intranet]."

quote:

Stuxnet: Computer worm opens new era of warfare

(CBS News) The most pernicious computer virus ever known wasn't out to steal your money, identity, or passwords. So what was the intricate Stuxnet virus after? Its target appears to have been the centrifuges in a top secret Iranian nuclear facility. Stuxnet showed, for the first time, that a cyber attack could cause significant physical damage to a facility. Does this mean that future malware, modeled on Stuxnet, could target other critical infrastructure -- such as nuclear power plants or water systems? What kind of risk do we face in this country? Steve Kroft reports.

http://www.cbsnews.com/83(...)-new-era-of-warfare/

quote:

Grote cyberaanval ontdekt in Midden-Oosten, lijkt op Stuxnet

quote:

Computers in het Midden-Oosten zijn getroffen door een computervirus dat informatie wist. Het tot Flame-gedoopte virus lijkt op de zogeheten Stuxnet-worm. Die laatste infecteerde in 2010 vooral Iraanse computers met als mogelijk doel het kernprogramma van het land te ontregelen.

Volgens anti-virusbedrijf Kaspersky is Flame ‘het meest geavanceerde cyberwapen tot nu toe’, schrijft de Israëlische krant Ha’aretz.

Mogelijk is de worm afkomstig van dezelfde ontwikkelaar als Stuxnet. Volgens het beveiligingsbedrijf bevat Flame nog andere elementen die alleen maar voorkwam in de Stuxnet-worm en niet in andere computervirussen. Vitaly Kamluk, malware-expert bij Kaspersky vermoedt dat Flame al sinds augustus 2010 actief is en ontwikkeld lijkt te zijn in opdracht van een regering.

Flame is een zogeheten ‘cyber-espionage worm’ en verzamelt en wist gevoelige informatie op computers in het Midden-Oosten. Kaspersky trof de worm aan in meer dan zeshonderd plekken in onder andere Iran, Soedan, Israël, Syrië, Libanon, Saoedi-Arabië en Egypte.

De Stuxnet-worm werd in juni 2010 ontdekt en bleek voornamelijk Iraanse computers als doelwit te hebben. Iran heeft sindsdien bevestigd dat de worm centrifuges, die gebruikt werden bij het verrijken van uranium, beschadigde. Stuxnet zou vermoedelijk zijn ontwikkeld door de Verenigde Staten en Israël om het omstreden Iraanse nucleaire programma te ontregelen.

quote:

Op vrijdag 1 juni 2012 11:44 schreef Geester het volgende:
AMSTERDAM - Het Stuxnetvirus is inderdaad door de VS en Israël geïnitieerd en kwam door een fout naar buiten. President Obama besloot ondanks het lek de cyberaanvallen op Iran door te zetten.

Dat schrijft The New York Times op basis van interviews met Amerikanen, Europeanen en Israëliërs die betrokken waren bij Stuxnet en de Amerikaanse aanvallen.

Het virus zou ontwikkeld zijn onder president George Bush, maar is pas gebruikt onder het bewind van Obama. In de zomer van 2010 lekte het virus volgens de bronnen per ongeluk uit door een programmeerfout.

.Het doel van Stuxnet is altijd geweest om het nucleaire programma van Iran aan te vallen. Obama zou zich na het lek afgevraagd hebben of deze missie in gevaar was gekomen, maar besloot uiteindelijk toch door te gaan.

In de weken na het lek werd Iran getroffen door een nieuwe versie van Stuxnet. Uiteindelijk werd 20 procent van alle centrifuges in de nucleaire faclititeit in Natanz uitgeschakeld door het virus.

Iran en diverse experts hebben altijd al het vermoeden geuit dat de Verenigde Staten en Israël achter Stuxnet zaten. De diverse bronnen bevestigen dit nu aan de Amerikaanse krant.

quote:

Op vrijdag 1 juni 2012 11:50 schreef UncleScorp het volgende:
Van de frontpage :

'Obama gaf opdracht voor Stuxnetaanval op Iran'

[..]

quote:

President Obama gaf opdracht de zelfontworpen worm Stuxnet te gebruiken om Iran aan te vallen. De president hoopte zo een oorlog tussen Israël en Iran te voorkomen, stelt The New York Times.

Het Stuxnet-project was al door president George W. Bush in gang gezet, maar zijn opvolger versnelde de cyberaanvallen die ermee werden uitgevoerd. The New York Times stelt dat Barack Obama opdracht gaf om door te gaan met de cyberoorlogsvoering nadat de worm ontsnapte.

Obama zet cyberaanval in
Nadat Stuxnet door een programmeerfout per ongeluk op de wereld werd losgelaten, vroeg de Amerikaanse president aan het toenmalige hoofd van de CIA of het project stopgezet moest worden. Deskundigen vertelden hem dat Iran weinig wist van het virus en dat het programma daar nog steeds schade aanrichtte.

Obama besloot daarom door te gaan met de cyberaanvallen. In de maanden die volgden frustreerde Stuxnet de productie van uranium in Iran door besturingschips in industriële centrifuges aan te vallen. Het virus verstoorde de motoren van de machines en hierdoor werd het verrijkingsproces van uranium lamgelegd.

Stuxnet van spyware naar malware
De voorloper van Stuxnet was een stukje spyware. Het virus moest gedetailleerde informatie verzamelen over hoe Iraanse computers de door Siemens geleverde centrifuges precies aansturen. Dit gebeurde toen George W. Bush nog president was. Met de verzamelde informatie begon het ontwerpen van de complexe worm die uiteindelijk het productieproces stil moest leggen.

De eerste variant van Stuxnet werd in 2008 uitgerold door spionnen en deels door onwetend personeel van de kerncentrale in het Iraanse Natanz. In de opstartfase werd het virus via usb-sticks gebruikt. In een later stadium werden 'meer geavanceerde methodes' gebruikt. Het virus benutte zero-day kwetsbaarheden in de aansturende Windows-pc's. Eenmaal geïnfecteerd werd de besturingschip (PLC) van de centrifuges verstoord.

Centrifuges afgevoerd
Het virus werkte op twee manieren. Ten eerste legde Stuxnet de PLC's van de centrifuges van Siemens plat. Ondertussen zorgde het virus ervoor dat personeel dacht dat het systeem goed functioneerde, zodat er niet werd ingegrepen. Toen er aanhoudende problemen ontstonden, moest personeel de machines in de centrale zelf in de gaten houden en doorgeven of er problemen waren. Uiteindelijk werden hele machines afgevoerd in de veronderstelling dat ze stuk waren.

The New York Times baseert het artikel over de Stuxnet-affaire op een boek van zijn eigen correspondent David E. Sanger. In 'Confront and Conceal', dat volgende week verschijnt, neemt de verslaggever Obama's 'Situation Room' onder de loep en beschrijft hij in detail de gesprekken die de president onder meer voerde over het cyberwapen. Sanger sprak met Amerikaanse, Europese en Israëlische autoriteiten die betrokken waren bij Stuxnet.

Oorlog Israël-Iran voorkomen
Volgens de aangehaalde anonieme bronnen gebruikte Obama de cyberaanval om te voorkomen dat Israël conventionele aanvallen op Iran zou uitvoeren. Het daaruit voortvloeiende conflict zou het Midden-Oosten op scherp kunnen zetten. De president vond daarom dat hij geen keus had.

Obama wil cyberwapens als Stuxnet niet te veel inzetten, schrijft de krant. Omdat de VS zelf zo zwaar op een it-infrastructuur leunt, kunnen dergelijke wapens - als andere staten kennis vergaren over de programmering - ook tegen Amerika worden gekeerd. Stuxnet zou de eerste cyberaanval van het land zijn. De aangehaalde anonieme bronnen stellen dat supermalware Flame ouder is en daarom geen onderdeel van het Amerikaanse virusproject is.
_{[url=http://webwereld.nl/nieuws/110701/-amerika-gebruikte-stuxnet-om-oorlog-te-voorkomen-.html[/url]}

quote:

Flame malware makers send 'suicide' code

The creators of the Flame malware have sent a "suicide" command that removes it from some infected computers.

Security firm Symantec caught the command using booby-trapped computers set up to watch Flame's actions.

Flame came to light after the UN's telecoms body asked for help with identifying a virus found stealing data from many PCs in the Middle East.

New analysis of Flame reveals how sophisticated the program is and gives hints about who created it.

Clean machine
Like many other security firms Symantec has kept an eye on Flame using so-called "honeypot" computers that report what happens when they are infected with a malicious program.

Described as a very sophisticated cyber-attack, Flame targeted countries such as Iran and Israel and sought to steal large amounts of sensitive data.

Earlier this week Symantec noticed that some Flame command and control (C&C) computers sent an urgent command to the infected PCs they were overseeing.

Flame's creators do not have access to all their C&C computers as security firms have won control of some of them.

The "suicide" command was "designed to completely remove Flame from the compromised computer", said Symantec.

The command located every Flame file sitting on a PC, removed it and then overwrote memory locations with gibberish to thwart forensic examination.

"It tries to leave no traces of the infection behind," wrote the firm on its blog.

Analysis of the clean-up routine suggested it was written in early May, said Symantec.

Crypto crash
At the same time, analysis of the inner workings of Flame reveal just how sophisticated it is.

According to cryptographic experts, Flame is the first malicious program to use an obscure cryptographic technique known as "prefix collision attack". This allowed the virus to fake digital credentials that had helped it to spread.

The exact method of carrying out such an attack was only demonstrated in 2008 and the creators of Flame came up with their own variant.

"The design of this new variant required world-class cryptanalysis," said cryptoexpert Marc Stevens from the Centrum Wiskunde & Informatica (CWI) in Amsterdam in a statement.

The finding gives support to claims that Flame must have been built by a nation state rather than cybercriminals because of the amount of time, effort and resources that must have been put into its creation. It is not yet clear which nation created the program.

quote:

CWI-cryptanalist ontdekt nieuwe cryptografische aanvalsvariant in Flame-virus

Cryptanalist Marc Stevens van het Centrum Wiskunde & Informatica (CWI) in Amsterdam, bekend van zijn 'kraak' van de MD5 hash-functie voor https-beveiliging in 2008, heeft deze week het recente Flame-virus geanalyseerd. Hij ontdekte dat voor deze spy malware een compleet nieuwe, tot nu toe onbekende cryptografische aanvalsvariant van zijn eigen MD5-aanval is gebruikt. Stevens analyseerde dit met nieuwe, door hem ontwikkelde forensische software. Aanvankelijk ging de onderzoeker ervan uit dat Flame zijn eigen, in 2009 openbaar gemaakte aanval gebruikte maar dit bleek niet het geval te zijn. "Flame gebruikt een geheel nieuwe variant van een 'chosen prefix collision' aanval om zich voor te doen als een legale beveiligingsupdate van Microsoft. Het maken van zon variant vereist cryptanalyse van wereldniveau," zegt Marc Stevens. "Het is dus zeer belangrijk om te investeren in cryptografisch onderzoek, om deze ontwikkelingen in de praktijk voor te blijven".

Het baanbrekende cryptografie-onderzoek is gedaan in CWI's Cryptology-groep, die onder leiding staat van prof.dr. Ronald Cramer. Deze groep onderzoekt fundamentele cryptografische vragen vanuit een breed wetenschappelijk perspectief, met name vanuit de wiskunde, computerwetenschap en natuurkunde. "Zonder ons fundamenteel wiskundig, cryptografisch onderzoek hadden we deze forensische software niet kunnen ontwikkelen", zegt Ronald Cramer. Het onderzoek van Marc Stevens maakt deel uit van diens promotieonderzoek, waarop hij op 19 juni aan het Mathematisch Instituut van de Universiteit Leiden hoopt te promoveren.
De gedetailleerde technische uitleg van CWI-onderzoeker Marc Stevens volgt onderaan dit bericht.

quote:

U.S., Israel developed Flame computer virus to slow Iranian nuclear efforts, officials say

quote:

The United States and Israel jointly developed a sophisticated computer virus nicknamed Flame that collected critical intelligence in preparation for cyber-sabotage attacks aimed at slowing Iran’s ability to develop a nuclear weapon, according to Western officials with knowledge of the effort.

The massive piece of malware was designed to secretly map Iran’s computer networks and monitor the computers of Iranian officials, sending back a steady stream of intelligence used to enable an ongoing cyberwarfare campaign, according to the officials.

quote:

The emerging details about Flame provide new clues about what is believed to be the first sustained campaign of cyber-sabotage against an adversary of the United States.

quote:

Op dinsdag 31 juli 2012 10:40 schreef UncleScorp het volgende:
Iran nuclear facilities hit by cyber attack that plays AC/DC's Thunderstruck at full volume

As far as malicious computer hacking is concerned, the most recent breach of security at Iran's nuclear facilities may not be very serious... unless you hate the music of Australian rock band AC/DC.
It has been alleged that unidentified computer hackers have forced workers at two of the country’s controversial nuclear facilities to endure AC/DC's hit song Thunderstruck repeatedly - and at full volume - sometimes in the middle of the night.
Of course, there has been no confirmation of the attack from Iran - the evidence stems from a series of e-mails purporting to be from the Atomic Energy Organisation of Iran.

An unnamed Iranian scientist e-mailed Mikko Hypponen, chief research officer for Finnish Internet security firm F-Secure, saying that the facilities at Natanz and Fordo, near Qom, were hit by a worm.
Apart from disabling the automated network at both sites, the malware seemed to have an interesting side effect of blaring out AC/DC at any given moment.
When contacted by MailOnline, Mr Hypponen confirmed that he had received the e-mails and that he had been e-mailing the scientist about the incident over the weekend.
He sent a redacted copy of the e-mail, which said: 'I am writing you to inform you that our nuclear program has once again been compromised and attacked by a new worm with exploits which have shut down our automation network at Natanz and another facility Fordo near Qom.'

Another e-mail made reference to AC/DC's Thunderstruck being played 'on several workstations in the middle of the night with the volume maxed out'.

It's not the first time that the Iranian nuclear programme has been the target of malware.
The destructive Stuxnet worm has now affected around 60 per cent of computers in Iran, and is widely held responsible for wrecking the centrifuge at the Nantaz nuclear facility.
Iran has confirmed that work has halted several times at the facility because of 'technical issues', and use of the centrifuge has dropped by

Stuxnet was thought at first to be the work of Israeli intelligence agency Mossad, but experts have recently turned the finger of suspicion to point at the U.S.
Many experts believe that the future of warfare will heavily rely on a nation's ability to 'spike' their enemies' computer networks.
Recently the Chinese have been suspected over a series of non-threatening incidents - such as the hacking of a U.S. automated sewerage system, or effectively taking command of two Nasa satellites.
Using music as a weapon has long been a trait of the US military, in conflicts including the invasion of Panama in the 1990s.

http://www.dailymail.co.u(...)erstruck-volume.html

quote:

Op dinsdag 31 juli 2012 12:45 schreef Chuck-N0rr1s het volgende: