Obama Order Sped Up Wave of Cyberattacks Against Iran

Via NYTimes -

From his first months in office, President Obama secretly ordered increasingly sophisticated attacks on the computer systems that run Iran’s main nuclear enrichment facilities, significantly expanding America’s first sustained use of cyberweapons, according to participants in the program.

Mr. Obama decided to accelerate the attacks — begun in the Bush administration and code-named Olympic Games — even after an element of the program accidentally became public in the summer of 2010 because of a programming error that allowed it to escape Iran’s Natanz plant and sent it around the world on the Internet. Computer security experts who began studying the worm, which had been developed by the United States and Israel, gave it a name: Stuxnet.

At a tense meeting in the White House Situation Room within days of the worm’s “escape,” Mr. Obama, Vice President Joseph R. Biden Jr. and the director of the Central Intelligence Agency at the time, Leon E. Panetta, considered whether America’s most ambitious attempt to slow the progress of Iran’s nuclear efforts had been fatally compromised.

“Should we shut this thing down?” Mr. Obama asked, according to members of the president’s national security team who were in the room.

Told it was unclear how much the Iranians knew about the code, and offered evidence that it was still causing havoc, Mr. Obama decided that the cyberattacks should proceed. In the following weeks, the Natanz plant was hit by a newer version of the computer worm, and then another after that. The last of that series of attacks, a few weeks after Stuxnet was detected around the world, temporarily took out nearly 1,000 of the 5,000 centrifuges Iran had spinning at the time to purify uranium.

This account of the American and Israeli effort to undermine the Iranian nuclear program is based on interviews over the past 18 months with current and former American, European and Israeli officials involved in the program, as well as a range of outside experts. None would allow their names to be used because the effort remains highly classified, and parts of it continue to this day.

These officials gave differing assessments of how successful the sabotage program was in slowing Iran’s progress toward developing the ability to build nuclear weapons. Internal Obama administration estimates say the effort was set back by 18 months to two years, but some experts inside and outside the government are more skeptical, noting that Iran’s enrichment levels have steadily recovered, giving the country enough fuel today for five or more weapons, with additional enrichment.

Whether Iran is still trying to design and build a weapon is in dispute. The most recent United States intelligence estimate concludes that Iran suspended major parts of its weaponization effort after 2003, though there is evidence that some remnants of it continue.

[...]

The impetus for Olympic Games dates from 2006, when President George W. Bush saw few good options in dealing with Iran. At the time, America’s European allies were divided about the cost that imposing sanctions on Iran would have on their own economies. Having falsely accused Saddam Hussein of reconstituting his nuclear program in Iraq, Mr. Bush had little credibility in publicly discussing another nation’s nuclear ambitions. The Iranians seemed to sense his vulnerability, and, frustrated by negotiations, they resumed enriching uranium at an underground site at Natanz, one whose existence had been exposed just three years before.

[...]

For years the C.I.A. had introduced faulty parts and designs into Iran’s systems — even tinkering with imported power supplies so that they would blow up — but the sabotage had had relatively little effect. General James E. Cartwright, who had established a small cyberoperation inside the United States Strategic Command, which is responsible for many of America’s nuclear forces, joined intelligence officials in presenting a radical new idea to Mr. Bush and his national security team. It involved a far more sophisticated cyberweapon than the United States had designed before.

--------------------------------------------------------------------

Those looking for a deeper look, can grab Flamer/Skywiper samples from Mila Parkour at the Contagio blog.

New Duqu Sample Found in the Wild

Via Symantec Security Response Blog (March 20, 2012) -

We recently received a file that looked very familiar. A quick investigation showed it to be a new version of W32.Duqu. The file we received is only one component of the Duqu threat however—it is the loader file used to load the rest of the threat when the computer restarts (the rest of the threat is stored encrypted on disk).

[...]

The compile date on the new Duqu component is February 23, 2012, so this new version has not been in the wild for very long. Checking the code we can see the authors have changed just enough of the threat to evade some security product detections, although this appears to have only been partially successful.

[...]

This is the first version of Duqu that we have found in 2012. Previously, we saw unique versions of Duqu released on the following dates:

• 2010-11-03
• 2010-11-03
• 2011-10-17

We also saw evidence that older versions had been used.

Although we do not have all of the information regarding this infection, the emergence of this new file does show that the attackers are still active. Without the other components of the attack it is impossible to say whether any new developments have been added to the code since we last saw a release from the group in November 2011.

------------------------------------------------------------------

CrySyS Duqu Detector Toolkit v1.23
http://www.crysys.hu/duqudetector.html

We are happy to introduce the Duqu Detector Toolkit v1.23 of CrySyS Lab as of 15/Mar/2012. Besides new versions of the previous detector tools that provide usability enhancements, we now also provide two brand new detector tools. The upgraded toolkit will provide better functionality for those who have already successfully used the former version.

DuQu Mystery Language Solved With the Help of Crowdsourcing

Via Wired.com (Threat Level) -

A group of researchers who recently asked the public for help in figuring out a mysterious language used in the DuQu virus have solved the puzzle, thanks to crowdsourcing help from programmers who wrote in to offer suggestions and clues.

The language, which DuQu used to communicate with command-and-control servers, turns out to be a special type of C code compiled with the Microsoft Visual Studio Compiler 2008.

Researchers at Kaspersky Lab, who put out the call for help two weeks ago after failing to figure out the language on their own, said they received more than 200 comments to a blog post they wrote seeking help, and more than 60 direct emails from programmers and others who made suggestions.

[...]

Most commenters who wrote in response to Kaspersky’s plea thought the code was a variant of LISP, but the reader who led them in the right direction was a commenter who identified himself as Igor Skochinsky and wrote in a thread posted to Reddit.com that he was certain the code was generated with the Microsoft Visual Studio Compiler and offered some cogent reasons why he believed this. Two other people who sent Kaspersky direct emails made crucial contributions when they suggested that the code appeared to be generated from a custom object-oriented C dialect — referred to as OO C — using special extensions.

This led the researchers to test various combinations of compiler and source codes over a few days until they found the right combination that produced binary that matched the style in DuQu.

The magic combination was C code compiled with Microsoft Visual Studio Compiler 2008 using options 01 and Ob1 in the compiler to keep the code small.

“Visual C can optimize for speed and it can optimize for size, or it can do some kind of balance between the two,” says Costin Raiu, director of Kaspersky’s Global Research and Analysis Team. “But they wanted obviously the smallest possible size of code” to get it onto victim machines via an exploit.

[...]

It suggests that whoever coded this part of DuQu was conservative, precise, and wanted 100 percent assurance that the code would work the way they wanted it to work.

But there was one other reason DuQu’s old-school programmers might have preferred C over C++ – its versatility. When C++ was initially developed, it was not standardized and wouldn’t compile in every compiler. C was more flexible. DuQu was delivered to Windows machines using a Microsoft Word zero-day exploit. But Raiu thinks DuQu’s programmers might have chosen C because they wanted to make sure that their code could be compiled with any compiler on any platform, suggesting they were thinking ahead to other ways in which their code might be used.

“Obviously when you create such a complex espionage tool, you take into account that maybe some day you will run it on servers, maybe you will want to run it on mobile phones or God knows what other devices, so you just want to make sure your code will work everywhere,” he says.

The Mystery of the Duqu Framework

Via Securelist.com (Kaspersky Lab) -

While analyzing the components of Duqu, we discovered an interesting anomaly in the main component that is responsible for its business logic, the Payload DLL. We would like to share our findings and ask for help identifying the code.

[...]

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.

The Duqu Framework: What was that?

After having performed countless hours of analysis, we are 100% confident that the Duqu Framework was not programmed with Visual C++. It is possible that its authors used an in-house framework to generate intermediary C code, or they used another completely different programming language.

We would like to make an appeal to the programming community and ask anyone who recognizes the framework, toolkit or the programming language that can generate similar code constructions, to contact us or drop us a comment in this blogpost. We are confident that with your help we can solve this deep mystery in the Duqu story.

Stuxnet/Duqu: The Evolution of Drivers

Via SecureList (Kaspersky Lab) -

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.

This platform can be conventionally named as ‘Tilded’ as its authors are, for some reason, inclined to use file names which start with "~d".

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.

[...]

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.

STRATFOR Dispatch: Countering Iran in the Covert World

http://www.stratfor.com/analysis/20111114-dispatch-countering-iran-covert-world

Director of Analysis Reva Bhalla examines how a recent chain of Iran-related events sheds light on the geopolitical environment in which Iran’s adversaries are operating.

Read more: Dispatch: Countering Iran in the Covert World | STRATFOR

McAfee Labs: Duqu - Consolidated Threat Report

http://download.nai.com/products/mcafee-avert/dil/Duqu_CTR_v1.9.pdf

McAfee Labs Consolidated Threat Reports bring together all the verified and corroborated intelligence on highly relevant and publically critical threats and events. Our researchers and engineers continually monitor the global threat landscape and provide relevant data to both our direct customers and to the public at large. We do this to assist in risk assessment and mitigation, as well as to “serve the greater good” as we cooperate and conduct research with other agencies and communities. Our Consolidated Threat Reports combine all the up-to-the-minute information from various sources (Global Threat Intelligence, blog entries, podcasts, whitepapers, presentations, and more.)

Iran Says Has Detected Duqu Computer Virus

Via MSNBC -

Iran said on Sunday it had detected the Duqu computer virus that experts say is based on Stuxnet, the so-called "cyber-weapon" discovered last year and believed to be aimed at sabotaging the Islamic Republic's nuclear sites.

The head of Iran's civil defense organization told the official IRNA news agency that computers at all main sites at risk were being checked and that Iran had developed software to combat the virus.

"We are in the initial phase of fighting the Duqu virus," Gholamreza Jalali, was quoted as saying. "The final report which says which organizations the virus has spread to and what its impacts are has not been completed yet.

"All the organizations and centers that could be susceptible to being contaminated are being controlled," he said.

News of Duqu surfaced in October when security software maker Symantec Corp said it had found a mysterious virus that contained code similar to Stuxnet.

While Stuxnet was aimed at crippling industrial control systems and may have destroyed some of the centrifuges Iran uses to enrich uranium, experts say Duqu appeared designed to gather data to make it easier to launch future cyber attacks.

[...]

Iran said in April it had been targeted by a second computer virus which it identified as "Stars." It was not immediately clear if Stars and Duqu were related but Jalali described Duqu as the third virus to hit Iran.

Tehran said Stuxnet had not inflicted serious damage before it was detected and blamed the United States and Israel for the virus which appeared to be aimed at crippling the nuclear program they say is aimed at making atomic weapons, a charge Iran denies.

The International Atomic Energy Agency issued a report last week that contained what it called credible evidence pointing to military dimensions to Iran's atomic activities, fueling demands in Washington and Europe for further sanctions.

Open Source Duqu Analysis Tool Sharing Update

Via NSS Labs -

Last Friday, NSS researchers announced their findings on Duqu on a blog post http://www.nsslabs.com/blog/2011/11/duqu-analysis-and-detection-tool.html. We also pointed to our open source tool https://github.com/halsten/Duqu-detectors that we've shared with the security research community. Since posting, the tool has been viewed over 18,000 times and 45 different forks have been created from the github repository in the few days it has been up.

We've set out to make a positive contribution to the community by giving code because we felt that taking action would yield the most positive results and would help others take action as well.

Today, CrySyS labs has released a great toolkit to detect duqu http://www.crysys.hu/duqudetector.html. It is open source and has compiled binaries ready for usage. They are taking action by helping the community and kudos to them for their contributions to detection for the community.

-----------------------------------------------------------------------------------------------------------------------------

CrySyS Duqu Detector Toolkit
http://www.crysys.hu/duqudetector.html

We developed a detector toolkit that combines simple detection techniques to find Duqu infections on a computer or in a whole network. The toolkit contains signature and heuristics based methods and it is able to find traces of infections where components of the malware are already removed from the system.

The intention behind the tools is to find different types of anomalies (e.g., suspicious files) and known indicators of the presence of Duqu on the analyzed computer. As other anomaly detection tools, it is possible that it generates false positives. Therefore, professional personnel is needed to elaborate the resulting log files of the tool and decide about further steps.

NSS Labs: Duqu Analysis & Detection Tool

http://www.nsslabs.com/blog/2011/11/duqu-analysis-and-detection-tool.html

NSS engineers have developed a scanning tool that can be used to detect all DuQu drivers installed on a system. This tool was developed in the hopes that additional drivers can be discovered to allow us to learn more about the functionality, capabilities and ultimate purpose of DuQu.

Based on layout of the drivers discovered so far, the NSS tool is capable of detecting 100% of drivers with zero false positives. Because it is using advanced pattern recognition techniques, it is also capable of detecting new drivers as they are discovered. Two new drivers were discovered after the tool was completed, and both were detected by the NSS tool with no updates required.

Duqu: Status Updates Including Installer with Zero-Day Exploit Found

Via Symantec Security Response Blog -

The group that initially discovered the original Duqu binaries, CrySyS, has since located an installer for the Duqu threat. Thus far, no-one had been able to recover the installer for the threat and therefore no-one had any idea how Duqu was initially infecting systems. Fortunately, an installer has recently been recovered due to the great work done by the team at CrySyS.

The installer file is a Microsoft Word document (.doc) that exploits a previously unknown kernel vulnerability that allows code execution. We contacted Microsoft regarding the vulnerability and they're working diligently towards issuing a patch and advisory. When the file is opened, malicious code executes and installs the main Duqu binaries.

[...]

The Word document was crafted in such a way as to definitively target the intended receiving organization. Furthermore, the shell-code ensured that Duqu would only be installed during an eight-day window in August. Please note that this installer is the only installer to have been recovered at the time of writing—the attackers may have used other methods of infection in different organizations. Unfortunately, no robust workarounds exist at this time other than following best practices, such as avoiding documents from unknown parties and utilizing alternative software. Fortunately, most security vendors already detect and block the main Duqu files, thereby preventing the attack.

Once Duqu is able to get a foothold in an organization through the zero-day exploit, the attackers can command it to spread to other computers. In one organization, evidence was found that showed the attackers commanding Duqu to spread across SMB shares. Interestingly though, some of the newly infected computers did not have the ability to connect to the Internet and thereby the command-and-control (C&C) server. The Duqu configuration files on these computers were instead configured not to communicate directly with the C&C server, but to use a file-sharing C&C protocol with another compromised computer that had the ability to connect to the C&C server. Consequently, Duqu creates a bridge between the network's internal servers and the C&C server. This allowed the attackers to access Duqu infections in secure zones with the help of computers outside the secure zone being used as proxies.

While the number of confirmed Duqu infections is still limited, using the above techniques we have seen Duqu spread across several countries. At the time of writing, Duqu infections have been confirmed in six possible organizations in eight countries.

The confirmed six possible organizations and their countries of presence include:

• Organization A - France, Netherlands, Switzerland, Ukraine
• Organization B - India
• Organization C - Iran
• Organization D - Iran
• Organization E - Sudan
• Organization F - Vietnam

Note that some organizations are only traceable back to an ISP and therefore all six may not be separate organizations. Furthermore, due to grouping by IP addresses, we cannot definitively identify the organizations.

Other security vendors have reported infections in the following countries:

• Austria
• Hungary
• Indonesia
• United Kingdom
• Iran - infections different from those observed by Symantec

[...]

You can find our updated whitepaper (version 1.3) here. In addition to further technical details we have added a 'Diagnostics' appendix for system administrators, which contains Duqu traces that may indicate an infection.

SecureWorks: Duqu Trojan Questions and Answers

http://www.secureworks.com/research/threats/duqu/

The Dell SecureWorks Counter Threat UnitSM (CTU) research team has been analyzing an emerging malware threat identified as the Duqu trojan. This Trojan horse has received a great deal of attention because it is similar to the infamous Stuxnet worm of 2010. This report includes answers to questions about this threat. CTU researchers have put countermeasures in place to detect Duqu C2 traffic, and they continue to monitor for new Duqu samples and update protections as needed.

McAfee Says Duqu No Threat To Utilities

Via CRN -

Security vendor McAfee has told utilities that the Duqu malware posed no threat, a concern raised by its similarities to the Stuxnet worm that attacked industrial control systems in Iran’s nuclear facility last year.

In a conference call Monday, David Hatchell, utilities account manager for McAfee, said there was “nothing to worry about at this point.”

“It (Duqu) is not targeting industrial control systems that we know of, and it’s not targeting any energy (companies) as far as we know,” Hatchell said.

[...]

“We can clearly see that this is used for espionage,” Peter Szor, senior director of research at McAfee Labs, said during the conference call. Very different industries have been targeted, including a hotel chain. While there was no confirmation from Iran, military industries in the country also could have been targeted. “Basically the goal of the malware is speculation at this point,” he said.

[...]

Szor said the company believes the drivers for Duqu were compiled in November 2010. The keylogger portion of Duqu, which records keyboard strokes, was compiled three months earlier. Szor believes earlier variants of Duqu may have been used to steal data in preparation for the Stuxnet attack. “That’s why I think personally that Duqu was a bit earlier than Stuxnet,” he said.

Variations of Duqu have been confirmed in England, Iran and the U.S., with reports of the Trojan in Austria, Hungary and Indonesia, McAfee said. Similarities to Stuxnet include the same malware-hiding rootkit, use of a stolen certificate authority from Taiwan to enable installation and a set timeframe for operation. Duqu was timed to delete itself after 36 days and the certificate was stolen from C-Media Electronics, according to McAfee.

-----------------------------------------------------------------

McAfee Labs: Duqu – Threat Research and Analysis
http://blogs.mcafee.com/wp-content/uploads/2011/10/Duqu1.pdf

Symantec: Duqu Status Update #1

Via Symantec Security Response Blog -

As mentioned in our previous blog, W32.Duqu was first brought to our attention by a research lab who had been investigating a targeted attack on another organization. This research was conducted by the Laboratory of Cryptography and System Security (CrySyS) in the Department of Telecommunications, Budapest University of Technology and Economics. CrySyS identified the infection and observed its similarity to W32.Stuxnet. They stated that no data was leaked as part of this attack.

We are grateful to CrySyS—sharing their findings allowed us to identify further attacks taking place. We have now determined that the originally targeted organization was one of a limited number of targets which include those in the industrial infrastructure industry. CrySyS has issued a statement regarding their analysis here: http://www.crysys.hu/.

The latest version of our white paper includes new information, such as details on further components we observed being downloaded onto a compromised machine. We will continue to provide updates to our white paper as further information comes to light.

Analysis: Duqu Targets Certificate Authorities

Via Threatpost.com -

With virus researchers scrambling to decode a new piece of malware that is based on the code of the Stuxnet worm, an analyst at McAfee is speculating that the new worm, Duqu, may have been created to target certificate authorities.

Writing on McAfee's research blog, Guilherme Venere and Peter Szor say that an analysis of the Duqu code by McAfee experts suggests that the worm was created "for espionage and targeted attacks against sites such as Certificate Authorities (CAs)." The McAfee analysis, if accurate, is the first to explicitly mention the type of organization that the Duqu worm targeted, and would suggest that those behind the worm intended to use it as a precursor to subsequent, targeted attacks.

Certificate authorities have been prominent targets of hackers in recent months.

[...]

McAfee said that the Duqu worm has been identified in "professional, targeted attacks" against CAs in parts of Europe, the Middle East, Asia and Africa. The researchers speculate that a digital certificate belonging to the firm C-Media, based in Taipei, was not stolen, but forged by a compromised CA.

The McAfee analysis fills in some details omitted from a longer analysis released by Symantec Corp on Tuesday. That research declined to name the kind of firm targeted by the worm, but provided a detailed analysis of the Duqu code, which bears a close resemblance to Stuxnet, with shared code used for the injection attack and several encryption keys and techniques that were used in Stuxnet.

Like Symantec's report, the analysis from McAfee says that it knows of only a few infections linked to Duqu, and says the worm doesn't appear to be designed to attack industrial control systems, as Stuxnet was.

W32.Duqu: The Precursor to the Next Stuxnet

Via Symantec Security Response Blog -

On October 14, 2011, a research lab with strong international connections alerted us to a sample that appeared to be very similar to Stuxnet. They named the threat "Duqu" [dyü-kyü] because it creates files with the file name prefix “~DQ”. The research lab provided us with samples recovered from computer systems located in Europe, as well as a detailed report with their initial findings, including analysis comparing the threat to Stuxnet, which we were able to confirm. Parts of Duqu are nearly identical to Stuxnet, but with a completely different purpose.

Duqu is essentially the precursor to a future Stuxnet-like attack. The threat was written by the same authors (or those that have access to the Stuxnet source code) and appears to have been created since the last Stuxnet file was recovered. Duqu's purpose is to gather intelligence data and assets from entities, such as industrial control system manufacturers, in order to more easily conduct a future attack against another third party. The attackers are looking for information such as design documents that could help them mount a future attack on an industrial control facility.

Duqu does not contain any code related to industrial control systems and is primarily a remote access Trojan (RAT). The threat does not self-replicate. Our telemetry shows the threat was highly targeted toward a limited number of organizations for their specific assets. However, it’s possible that other attacks are being conducted against other organizations in a similar manner with currently undetected variants.

The attackers used Duqu to install another infostealer that could record keystrokes and gain other system information. The attackers were searching for assets that could be used in a future attack. In one case, the attackers did not appear to successfully exfiltrate any sensitive data, but details are not available in all cases. Two variants were recovered, and in reviewing our archive of submissions, the first recording of one of the binaries was on September 1, 2011. However, based on file compile times, attacks using these variants may have been conducted as early as December 2010.

[...]

Duqu shares a great deal of code with Stuxnet; however, the payload is completely different. Instead of a payload designed to sabotage an industrial control system, the payload has been replaced with general remote access capabilities. The creators of Duqu had access to the source code of Stuxnet, not just the Stuxnet binaries. The attackers intend to use this capability to gather intelligence from a private entity to aid future attacks on a third party. While suspected, no similar precursor files have been recovered that predate the Stuxnet attacks.

You can find additional details in our paper here. The research lab that originally found the sample has allowed us to share their initial report as an appendix. We expect to make further updates over the coming days.

Key points:

• Executables using the Stuxnet source code have been discovered. They appear to have been developed since the last Stuxnet file was recovered.
• The executables are designed to capture information such as keystrokes and system information.
• Current analysis shows no code related to industrial control systems, exploits, or self-replication.
• The executables have been found in a limited number of organizations, including those involved in the manufacturing of industrial control systems.
• The exfiltrated data may be used to enable a future Stuxnet-like attack.

-----------------------------------------------------------------------------

Whitepaper - W32.Duqu: The Precursor to the Next Stuxnet
http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/w32_duqu_the_precursor_to_the_next_stuxnet.pdf

W32.Duqu - Summary
http://www.symantec.com/business/security_response/writeup.jsp?docid=2011-101814-1119-99