Daily Archives: October 12, 2018

NBlog Oct 13/2 – CERT NZ goes phishing

CERT NZ (apparently) has once again circulated an email warning about phishing, containing a distinctly phishy link to "READ MORE INFORMATION". The hyperlink leads from there to certnz.cmail20.com with a tracker-type URL tail.

Unlike most of the intended audience, I guess, I'm cyber-smart enough to check out the whois record: cmail20.com domain is registered to Campaign Monitor Pty Ltd of New South Wales - presumably a legitimate mass emailer/marketing company whose services are being used by CERT NZ to circulate the warnings - but that's not the point: the fact is that the embedded link target is patently not CERT NZ's own domain.

What's more, the body of the email is a rather vaguely-worded warning, not entirely dissimilar to many a classic phisher. "Nasty stuff is going to happen unless you do something" just about sums it up. It isn't even addressed to me by name, despite me being required to supply my name and email address when I signed up for CERT NZ's "updates". They know who I am.

I've notified CERT NZ about this kind of thing privately before, to no avail, so this time around I'm going public, here on the blog.

CERT NZ, you are perpetuating the problem. Wake up guys! It's simply not good enough. I expect more of you. Your sponsors, partners and taxpayers expect more of you. NZ expects more of you.

Is it really that difficult to either drop the marketing tracking, or at least to route clickers via cert.govt.nz first, with a redirect from there to the tracker?

Is there nobody in CERT NZ with sufficient clue to appreciate and respond to such an obvious concern? 

Am I wasting these bytes? Hello, CERT NZ! Anyone home?

Ironically, CERT NZ has allegedly been promoting the past five days as "Cyber Smart Week 2018", which as far as I can make out appears to consist of a single web page on CERT NZ's website expanding a little on these four simple tips:
  1. Use unique passwords
  2. Turn on 2FA
  3. Update your apps
  4. Check your privacy

Admirably brief ... but there's nothing explicit about phishing or business email compromise, nor social engineering, scams and frauds. No obvious links to further information. 

Ironically, again, the Cyber Smart page ends: 
"Report any cyber security issue you experience to CERT NZ. We’ll help you identify it and let you know what the next steps are to resolve it. We’ll also use the information to create advice and guidance for others who might be experiencing the same issue."
Been there, done that, got precisely nowhere. I despair.

Next time I receive a phishing-like email from CERT NZ, I'll take it up with the news media. Maybe they care as much as me.

NBlog Oct 13 – little boxes, little boxes

In preparation for a forthcoming NoticeBored security awareness and training module on business continuity, I'm re-reading The Power of Resilience by Yossi Sheffi (one of the top ten books I blogged about the other day). 

It's a fascinating, well-written and thought-provoking book. Yossi uses numerous case studies based on companies with relatively mature approaches to business continuity to illustrate how they are dealing with the practical issues that arise from today's complex and dynamic supply chains - or rather supply networks or meshes.

Risk assessment is of course an important part of business continuity management, for example:
  • Identifying weak, unreliable or vulnerable parts of the massive global 'system' needed to manufacture and supply, say, aircraft or PCs;
  • Determining what if anything can be done to strengthen or bolster them; and 
  • Putting in place the necessary arrangements (controls) to make the extended system as a whole more resilient.
Yossi covers the probability plus impact approach to risk analysis that I've described several times on this blog, with (on page 34) a version of the classic Probability Impact Graph:

The dotted lines divide the example PIG into quadrants forming the dreaded 2x2 matrix much overused by consultants and politicians. He discusses more involved versions including the 5x5 matrix used by 'a large beverage company' with numbers arbitrarily assigned to each axis - not the obvious 1,2,3,4,5 linear sequence but (for some barely credible reason) 1,3,7,15 and 31 along the impact axis and 1,2,4,7 and 11 for likelihood or probability, with the implication that they then multiply the values to generate their risk scores.

That appears straightforward but is in fact an inappropriate application of mathematics since the numbers are not cardinal numbers or percentages denoting specific quantities but category labels (ordinals). The axes on the 2x2 matrix could have been labeled green and red or Freda and Fred: it makes no sense to multiply them together ... but that's exactly what happens, often.

Yossi's example PIG above demonstrates another problem with the approach: "Earthquake" is shown across the middle of the impact axis, spanning the Light and Severe categories. So which is it? If it must be in a box, which box?

The obvious response is either to shift "Earthquake" away from the boundary, arbitrarily, or add another central category, dividing that axis into three ... which simply perpetuates the issue since there are so few clear columns on the PIG to draw the lines. Likewise with the rows.

What's more, earthquakes vary from barely detectable up to totally devastating in impact, way more range than the PIG shows. Those barely-detectable quakes happen much more frequently than the devastating ones (fortunately!) hence a more accurate representation would be a long diagonal shape (a line?  An oval?  A banana? Some irregular fluffy cloud maybe?) mostly sloping down from left to right, crossing two or three of the four quadrants and extending beyond the graph area to the left and right. A single risk score is inappropriate in this case, in almost all cases in fact since most risks show the same effect: more significant and damaging incidents typically occur less often than relatively minor ones. We can't accurately determine where they fall on the PIG since the boundaries are indistinct. We seldom have reliable data, especially for infrequent incidents or those that often remain somewhat hidden and perhaps totally unrecognized as such (e.g. frauds). 

As if that's not enough already, the whole situation is dynamic. The PIG is a snapshot representing our understanding at a single point in time ... but some of the risks may have materially changed since then, or could materially change in an instant. Others 'evolve' gradually, while some vary unpredictably over the time horizons typical in business. Some of them may be related or linked, perhaps even inter-dependent (e.g. "Computer virus", or more accurately "Malware",  is one of many causes of "IT system failure", hence is it appropriate to show those as two distinct, separated risks on the PIG?). 

The possibility of cascading failures is one of Yossi's core messages: it is not sufficient or appropriate to consider individual parts of a complex system in isolation - "the straw that broke the camel's back" or "the butterfly effect". A seemingly insignificant issue in some obscure part of a complex system may trigger a cascade that substantially magnifies the resulting impact. System-level thinking is required, a wholly different conceptual basis.

Given all the above complexity, and more, it makes sense (I think) to dispense with the categories and quadrants, the dodgy mathematics and the pretense at being objective or scientific, using the PIG instead as a tool for subjective analysis, discussion and hopefully agreement among people who understand and are affected by the issues at hand. An obvious yet very worthwhile purpose is to focus attention first and foremost on the "significant" risks towards the top right of the PIG plus those across the diagonal from top left to bottom right, while downplaying (but not totally ignoring!) those towards the bottom left. That's the reason the NoticeBored PIGs have no specific values on the axes, no little boxes, a variety of sizes and shapes of text indicating the risks, overlaid on a background simplistically but highly effectively colored red-amber-green. We're not ignoring the complexities - far from it: we're consciously and deliberately simplifying things down to the point that experts and ordinary people (managers, mostly) can consider, discuss and decide stuff, especially those red and amber zone risks. Are they 'about right'? What have we missed here? Are there any linkages or common factors that we ought to consider? It's a pragmatic approach that works very well in practice, thank you, as both an awareness and a risk management tool.

I commend it to the house.

Kanye’s Password

Everyone and his brother, inside of infosec and outside has been chortling at Kanye’s iPhone password.   Its 00000.

Not everyone is in on the joke.
Some express OUTRAGE.  “how dare you share that man’s password” (it was on CNN, its out there now).
Some (and these remind me of the 4D Chess MAGA people) theorize that Kanye is thinking 12 steps ahead.  He knew his password input would be on camera while at the White House so he temporarily set it to 00000.
And the last were the virtue signalers I mentioned.  “how dare you password shame Kanye, at least he has a password.”

And it is true.  By HAVING a password, encryption is enabled on the iPhone.
it is also true that few of us would be able to exploit knowledge of Kanye’s password as we don’t have hands on his phone.

But lets be honest.  A password of 00000 is pretty hilarious.

Self disclosure – one of my older accounts has failed the LastPass password audit because the password was compromised previously, and its used in more than one place.   But given the difficulty in updating this particular password, and the low risk level, I let it be until a forced password change recently.   Sometimes you just use dumb passwords.  And if it filmed I’d be razzed for it too.

The post Kanye’s Password appeared first on Roger's Information Security Blog.

The Dangers of Linking Your Apple ID to Financial Accounts

The digital wallets of Chinese citizens are under attack thanks to a few bad apples. A recent string of cyberattacks in China utilized stolen Apple IDs to break into customers’ accounts and steal an undisclosed amount of money, according to a Bloomberg report. Almost immediately, Chinese e-transaction giants Tencent Holdings and Alipay warned their customers to monitor their accounts carefully, especially those who have linked their Apple IDs to Alipay accounts, WeChat Pay or their digital wallets and credit cards.

While Alipay works with Apple to figure out how this rare security breach happened and how hackers were able to hijack Apple IDs, they’re urging customers to lower their transaction limits to prevent any further losses while this investigation remains ongoing. Because Apple has yet to resolve this issue, any users who have linked their Apple IDs to payment methods including WeChat Pay — the popular digital wallet of WeChat which boasts over a billion users worldwide and can be used to pay for almost anything in China — remain vulnerable to theft. Apple also advises users to change their passwords immediately.

This security breach represents a large-scale example of a trend that continues to rise: the targeting of digital payment services by cybercriminals, who are capitalizing on the growing popularity of these services. Apple IDs represent an easy entry point of attack considering they connect Apple users to all the information, devices and products they care about. That interconnectivity of personal data is a veritable goldmine for cybercriminals if they get their hands on something like an Apple ID. With so much at stake for something as seemingly small as an Apple ID, it’s important for consumers to know how to safeguard their digital identifiers against potential financial theft. Here are some ways they can go about doing so:

  • Make a strong password. Your password is your first line of defense against attack, so you should make it as hard as possible for any potential cybercriminals to penetrate it. Including a combination of uppercase and lowercase letters, numbers, and symbols will help you craft a stronger, more complex password that’s difficult for cybercriminals to crack. Avoid easy to guess passwords like “1234” or “password” at all costs.
  • Change login information for different accounts. An easy trap is using the same email and password across a wide variety of accounts, including Apple IDs. To better protect your Apple ID, especially if it’s linked to your financial accounts, it’s best to create a wholly original and complex password for it.
  • Enable two-factor authentication. While Apple works on identifying how these hackers hijacked Apple IDs, do yourself a favor and add an extra layer of security to your account by enabling two-factor authentication. By having to provide two or more pieces of information to verify your identity before you can log into your account, you place yourself in a better position to avoid attacks.
  • Monitor your financial accounts. When linking credentials like Apple IDs to your financial accounts, it’s important to regularly check your online bank statements and credit card accounts for any suspicious activity or transactions. Most banks and credit cards offer free credit monitoring as well. You could also invest in an identity protection service, which will reimburse you in the case of identity fraud or financial theft.

Stay on top of the latest consumer and mobile security threats by following me and @McAfee_Home on Twitter, listening to our podcast Hackable?, and ‘Liking’ us on Facebook.

The post The Dangers of Linking Your Apple ID to Financial Accounts appeared first on McAfee Blogs.

GAO Report on Equifax

I have regularly asked why we don’t know more about the Equifax breach, including in comments in “That Was Close! Reward Reporting of Cybersecurity ‘Near Misses’.” These questions are not intended to attack Equifax. Rather, we can use their breach as a mirror to reflect, and ask questions about how defenses work, and learn things we can bring to our own systems.

Ian Melvin was kind enough to point out a GAO report, “Actions Taken by Equifax and Federal Agencies in Response
to the 2017 Breach
.” As you’d expect of a GAO report, it is level headed and provides a set of facts.

However, I still have lots of questions. Some very interesting details start on page 11:

Equifax officials added that, after gaining the ability to issue system-level commands on the online dispute portal that was originally compromised, the attackers issued queries to other databases to search for sensitive data. This search led to a data repository containing PII, as well as unencrypted usernames and passwords that could provide the attackers access to several other Equifax databases. According to Equifax’s interim Chief Security Officer, the attackers were able to leverage these credentials to expand their access beyond the 3 databases associated with the online dispute portal, to include an additional 48 unrelated

The use of encryption allowed the attackers to blend in their malicious actions with regular activity on the Equifax network and, thus, secretly maintain a presence on that network as they launched further attacks without being detected by Equifax’s scanning software. (Editor’s note: I’ve inverted the order of the paragraphs from the source.)

So my questions include:

  • How did the attackers get root?
  • Why wasn’t the root shell noticed? Would our organization notice an extra root sell in production?
  • How did they get access to the other 48 databases?
  • Why didn’t the pattern of connections raise a flag? “As before, Equifax
    officials stated that the attackers were able to disguise their presence by
    blending in with regular activity on the network.” I find this statement to be surprising, and it raises questions: Does the dispute resolution database normally connect to these other databases and run the queries which were run? How was that normal activity characterized and analyzed? Encryption provides content confidentiality, not meta-data confidentiality. Would we detect these extra connections?

Specifically, while Equifax had installed a device to inspect network traffic for evidence of malicious activity, a misconfiguration allowed encrypted traffic to pass through the network without being inspected. According to Equifax officials, the misconfiguration was due to an expired digital certificate. The certificate had expired about 10 months before the breach occurred, meaning that encrypted traffic was not being inspected throughout that period.

Would your organization notice if one of hundreds or dozens of IDSs shut up for a week, or if one ruleset stopped firing?

Google and Android have your back by protecting your backups

Android is all about choice. As such, Android strives to provide users many options to protect their data. By combining Android’s Backup Service and Google Cloud’s Titan Technology, Android has taken additional steps to securing users' data while maintaining their privacy.

Starting in Android Pie, devices can take advantage of a new capability where backed-up application data can only be decrypted by a key that is randomly generated at the client. This decryption key is encrypted using the user's lockscreen PIN/pattern/passcode, which isn’t known by Google. Then, this passcode-protected key material is encrypted to a Titan security chip on our datacenter floor. The Titan chip is configured to only release the backup decryption key when presented with a correct claim derived from the user's passcode. Because the Titan chip must authorize every access to the decryption key, it can permanently block access after too many incorrect attempts at guessing the user’s passcode, thus mitigating brute force attacks. The limited number of incorrect attempts is strictly enforced by a custom Titan firmware that cannot be updated without erasing the contents of the chip. By design, this means that no one (including Google) can access a user's backed-up application data without specifically knowing their passcode.

To increase our confidence that this new technology securely prevents anyone from accessing users' backed-up application data, the Android Security & Privacy team hired global cyber security and risk mitigation expert NCC Group to complete a security audit. Some of the outcomes included positives around Google’s security design processes, validation of code quality, and that mitigations for known attack vectors were already taken into account prior to launching the service. While there were some issues discovered during this audit, engineers corrected them quickly. For more details on how the end-to-end service works and a detailed report of NCC Group’s findings, click here.

Getting external reviews of our security efforts is one of many ways that Google and Android maintain transparency and openness which in turn helps users feel safe when it comes to their data. Whether it’s 100s of hours of gaming data or your personalized preferences in your favorite Google apps, our users' information is protected.

We want to acknowledge contributions from Shabsi Walfish, Software Engineering Lead, Identity and Authentication to this effort

Here’s how to see if you were affected by Facebook’s breach

Today, Facebook provided additional information on the data breach it disclosed last month. Whereas it initially said up to 50 million users might have been affected, it now reports that 30 million were impacted by the breach. By exploiting a system vulnerability, attackers were able to steal digital keys called access tokens from those 30 million users, and Facebook has now laid out how those users were affected. The company is also notifying those impacted, but if you don't want to wait to be notified, you can check if your account was affected through this link.

Source: Facebook

Facebook says recent data breach wasn’t ‘related to the midterms’

Even though the number of users affected by Facebook's most recent hack was lowered to 29 million, from 50 million, it's still safe to say the attack was worse than originally thought. That's because we now know that the breach, which Facebook revealed a couple of weeks ago, exposed very detailed information of 14 million of those users, including their username, birthdate, gender, location, relationship status, religion, hometown, self-reported current city, education, work, the devices they used to access Facebook and the last 10 places they checked into (or were tagged in) on the site. The attackers, whose identities Facebook won't reveal because of an ongoing FBI investigation, were also able to view which people/Pages were followed by these 14 million users, as well as their 15 most recent searches on Facebook.

Threat Roundup for October 5 to October 12

Today, as we do every week, Talos is giving you a glimpse into the most prevalent threats we’ve observed this week — covering the dates between Oct. 5 and 12. As with previous roundups, this post isn’t meant to be an in-depth analysis. Instead, we will summarize the threats we’ve observed by highlighting key behavioral characteristics and indicators of compromise, and discussing how our customers are automatically protected from these threats.

As a reminder, the information provided for the following threats in this post is non-exhaustive and current as of the date of publication. Additionally, please keep in mind that IOC searching is only one part of threat hunting. Spotting a single IOC does not necessarily indicate maliciousness. Detection and coverage for the following threats is subject to updates, pending additional threat or vulnerability analysis. For the most current information, please refer to your Firepower Management Center, Snort.org, or ClamAV.net.

The most prevalent threats highlighted in this roundup are:

  • Win.Malware.Emotet-6710203-0
    Emotet is a banking trojan that has remained relevant due to its continual evolution and its ability to bypass antivirus products.
  • Win.Malware.Fuerboos-6712723-0
    Fuerboos is a backdoor trojan that monitors user activity and captures that information to eventually send it back to a server. It utilizes a double flux network where multiple hosts act as proxies to further prevent researchers from locating the actual malicious server.
  • Win.Dropper.Demp-6714293-0
    Demp drops DLL files that are later injected into the explorer process. It is also capable of accepting commands from a command and control (C2) server and exfiltrating system information.
  • Win.Malware.Dgbv-6714452-0
    DGBV is malware written in Delphi and is packed with Inno Setup, a free software installation system. Once deployed, DGBV collects sensitive information from the infected host and sends it to a C2, including browser password databases.
  • Doc.Downloader.Valyria-6713303-0
    Valyria is a malicious Word document family that is used to distribute other malware. This campaign is currently spreading Emotet.
  • Win.Downloader.Dofoil-6714608-0
    Dofoil, AKA SmokeLoader, is primarily used to download and execute additional malware. Read more about this threat on our blog.
  • Win.Malware.Zbot-6714649-0
    Zbot, also known as Zeus, is trojan that steals information such as banking credentials. It has numerous capabilities, including key-logging using methods such as key-logging and form grabbing.



Indicators of Compromise

Registry Keys
  • PEM6A4
  • PEM6B0
IP Addresses contacted by malware. Does not indicate maliciousness
  • 96[.]114[.]157[.]81
  • 24[.]203[.]4[.]40
  • 216[.]137[.]249[.]154
  • 98[.]191[.]228[.]168
  • 41[.]204[.]202[.]41
Domain Names contacted by malware. Does not indicate maliciousness
  • smtp[.]aavanira[.]com
Files and or directories created
  • N/A
File Hashes
  • 0eba4bf670ebd4381150a0d9e1fd113561898849ac53fd22e0eee1afe05de77d
  • 12faaf05baa1ead6dd6559f2eed72373d78eff2e462c59fc055ac098b8ad7d38
  • 1affd33a6864d27ffb7b2398630c06610a3c9d81d0f84548b7a66c431d2b733a
  • 1d75775d6b05c878611b678b1bceacc76c888fb086ad2c47111aa696dad4b59f
  • 1fca28e3264af2703e3e221b9193e93351b3b9ef3474643fb27d589b8c10840e
  • 20dec98c8003e986251cc8a765a931783203ec75eae436e9df2248a465321e53
  • 213395fba51bb15feb10d201b78df2a8c4bfcd25498f672b02391a77647cb781
  • 36bc6b1def213cb8f10670fa3d574f831fdd63a9a5f2a66f66c1d580dfb75955
  • 3e9e1062c311605bb78e8df525eaa11268ad5b547ae9295669a0c751e16f5a13
  • 49a9333f65eb8a84e74b14a928d7ad94737c95117eae62e87bf84617637f04a1
  • 6c231427d0fc1cf9ad431c7c5a8973db04e5a5cd2ef3205d6f544ae3b20a57f8
  • 74e5ce08015255e67a1e21dfd2e44afb613a329b4bc6a4a678d1fb18e0d45412
  • 8e0652595b5c7661ce08ef8c986ad31cef38020f80f7afcd500a9acbdd6ae774
  • 995cca730bcdeecd0e497999e7ff2a4a6659fae45130e05599f0d716125c00a3
  • a5a882b548a7b4faa705f9defef61566fdc778c983f58b71578896448f2721fb
  • aa9c066ef31f701399812d51bf46231d88911bf062098e4428e8768002d6274c
  • af253123e7bc9a5732d21ecca3d9d24db4c3a1d616fc8d8b14c3bdaa97bac3b9
  • b7fab8bd7cfc07cf11cbf012b9d926cc4953df301b4d5bf8df12106d9d748aca
  • c0fa19dd12030a9c24375a25dbfd413a6fd123b2b0451902af767167b313aad5
  • c1ea9d852216d51cffbed3da3ef2fc23156f523096f900a9127ca91cbda542fb
  • ed96c1d12554779cdef56ebd87ac4390815c006cb7771608297377cabc3a8023
  • fb05b1c6edb8961620fff003d4ea496d889e5e217f28e77a7d6c37a6c73e3f17


Screenshots of Detection





Indicators of Compromise

Registry Keys
  • N/A
  • !PrivacIE!SharedMem!Mutex
  • SmartScreen_ClientId_Mutex
IP Addresses contacted by malware. Does not indicate maliciousness
  • 54[.]39[.]175[.]170
  • 51[.]68[.]239[.]251
Domain Names contacted by malware. Does not indicate maliciousness
  • s928eid19oqieuqoeu[.]com
  • 11wiwy19wpqoqsos292uwoqow83[.]com
Files and or directories created
  • %LocalAppData%\Temp\04pnjlnm.cmdline
  • %LocalAppData%\Temp\04pnjlnm.dll
  • %LocalAppData%\Temp\04pnjlnm.out
  • %LocalAppData%\Temp\F256.bin
File Hashes
  • 033a197eb9289e06f7541f3b66fdf308d8abce2fc4e7269776a664bde3e3945d
  • 05f4d4b6a171b5dc1023b75983a6203f2a958f39a821c3483d05ee30c3a972d5
  • 07783f32930a4b4b595976f347fc6272c1ac67e73b173a962ee4cb6cc92fd757
  • 07b55edfd0e61cd0e120e0245dfe1dce775405c1aa12ea7717afdf3f55fae0a4
  • 0d87696146e48e023816ca67ff8bc449bc326e6592d1fb588283eed4d6b80357
  • 0df85fbe16e6252a12ad9096590d3f1b9af548f0972edfb9393521ac86ca26cd
  • 10c075586237c573630d7361e55b910c38f67d9c8255592858b80e57c4c5b796
  • 11a4da86de7617dbe52f7b89818626f10b4c4c326b71b2a7c8f4477293b5de92
  • 12124b503f2989dea4dc2bbb9edc1054971075d7b326836693f5623ca46ffd1b
  • 13a05b5af10b15d1ad5e296c75507b65c70f669cb5e48f3174fc28d9053e1ee9
  • 14881ef04a4af32b3cd29d413557c5bee31efe0d1f35db0b5a570dac7dc0c6cc
  • 19e9de7427f46bac7637d0a9a633d3b34d8e515df48b39229c1b673bf5105681
  • 1df9d199d46a2f8f0b345b3fd3fdd77ac7c0449df03e156f508b3d0d1600607c
  • 1fae65f06e00e08ec2d60519cd416335c7b26f0e92d4ef2b65e72f5a3d166172
  • 1fd513421c26ae15b03dae61fe9932fbe7fc9bcc65a268867fed5a3987df18c0
  • 23d849dd6ce38c93fb47adfdc6a29c28d7d9993534fc35eb9745396dab3c2edc
  • 25466f6ed1011635a332ef93c465d5f6803e4099a09b8e3764f3d29a012e70fb
  • 2773a65c5791d9382e498e84c352d5175445669c5b566c3bca150d9c320ebfe0
  • 27ed0a3e9ca95105f734e9aa55fe6a65fafb196a291913af197a48c263865685
  • 2ab936982eadd726bab936ab68bef211b3ffafd6f6f36dd1406830db72aae529
  • 2b728ccccb05a1b03cb4ad4ccac320d74feeafe2f2be0a06f635fd9f56daec65
  • 2b7cf52c1c83af3ad9349e551619be5031db6f58049cf7697e155ad25dd6519a
  • 2e534b2373b08930ff05e39491405c6580be5bfd194ec6b9798dad7b5ba841e3
  • 2ede38df97248bfea976a6985427a1f6dc3206b96dab218e14354653192576e8
  • 30e2c4ce1d069cfbd7b3be5025a022e432a681b38dc1b60d2d83e51a160056be


Screenshots of Detection





Indicators of Compromise

Registry Keys
  • <HKCU>\Software\Microsoft\Windows\Currentversion\Run
  • N/A
IP Addresses contacted by malware. Does not indicate maliciousness
  • 203[.]78[.]107[.]112
Domain Names contacted by malware. Does not indicate maliciousness
  • www[.]siamrich[.]co[.]th
Files and or directories created
  • %AppData%\Albea\wuzuo.xuo
  • %AppData%\Ebodyk\ruce.exe
  • %AppData%\Ogno\ruof.kuh
File Hashes
  • 1179d11e07f6bfc5e19bd4e715ffcc9ea8bb3c0e7cc6d4fe4e462f5433dab8c5
  • 13bcb923aa00b7399e31fce0ad7c73c95d046b9fd9cc61fdad54a2001a24ef52
  • 1751b6a0e5e0eb5709e63cf05f362e0256aff5c56bf919ce510cfa88836e7a3f
  • 1dade14775862a6978810f9edc71679d7d7c128d469f2275258717ed88906d25
  • 2e224ae755c32a914bc7be948a805b358fcc26ff1a95a04c6a05117501b164f3
  • 5cb4338d783396dea3968b5f1ef16a3db4fca907a2c03e715aaafc61200eb20b
  • 68f758a0d97e4f1a3dfa4c637c3d19332217c1c0fdf04e416d708cb9a7f47e10
  • 7ee688e6cc5e3d6f27cb09c82842d7094f8de6d0900fba7c7686fe6e5edbb314
  • 87dc7ea718d5dc4916bdee2a1b928921babc884f1754d5e01152b8bc868b6124
  • 8f615ff9e9bafa6c0278fd4914bad01d4457689ab7a271d674ef0c7da569390c
  • 967cf3782024def1f1bb478d12ab3658aa9081188a5f8a1b97bfb9daf37f1d98
  • b816f28c64b91a88e8675191bdfc6fb6cee14808a475bd23594637a033bfa3a9
  • cc7264cc4f7b0692935640eeaaccd71319a0459fe094f9b16cd055fa3cfb6ad7
  • cf020f6d42ef17fb0afcb5d9abf51721fd2de655e61a565fbc3891574b278e57
  • eb88635d91cbb0f85d235a2aec00fca2217fc16f076a5fb79cb6764c16eb002c
  • ee8a67421a69bfd280bb7429e19efb3ee7fc403db592315963934409c841fed4
  • f7589669d7b57285986b0ec280083fe66fb80aadc8b9d0ff279daac8459eb50d
  • fbda080d12a9da511c5763b8269b393c3f76a511ff05a4c740cb017d933605fc
  • fc9f06ce525f321e664d8a9c94bc7d8fe8420aadead196300451f5ade6867bff


Screenshots of Detection




Indicators of Compromise

Registry Keys
  • N/A
  • 3749282D282E1E80C56CAE5A
IP Addresses contacted by malware. Does not indicate maliciousness
  • 45[.]122[.]138[.]6
Domain Names contacted by malware. Does not indicate maliciousness
  • filitimonieenama[.]com
Files and or directories created
  • %AppData%\D282E1\1E80C5.lck
File Hashes
  • 1d9cbdafba2ed47d7a420ea42b690664d06245f5c25b94cfdcbc3a1a33499164
  • 23100d1c82e06b6b899d4f04cfdd393c05ca656767c7a7648981fd14973ee7a6
  • 418d65586f05d278901417b0c8d7c4752ea7415b2c8fa6c093a460a434c02c52
  • 58be850629c361f619da13c0106a8e7a1e61e07855fc23aa956e283a626ccaa8
  • 60ae0309004f39b41fb96fa278219875668ad139974a35a6b5bee5ad42caf985
  • 6ce5513f53a548aad74508dd376456b2cb7a91323c4ea27e2410ead309300b86
  • 78e19745a107b3d196d476f81feeeb01663787869910f369b176c23c3536aaca
  • 7dfd6d093b0fd406f734d92b3fac5e59631c0649170670c220743be74344634f
  • 8b6348185f0d21c809f2d924f868bdf8ee2ea7b9ba59c41783a35817dfaf17c9
  • 919d0e14a92fee33c9ec402b0e02b5282fd5cae502aadc2c490d3bfdf4350ad8
  • bbd0a4000591033769be4ab26ca2fbe334440c4b56acb329433fc98c3405ceff
  • c0a6d9b38153cc61dd042e7b9ea02df9b8d0958f27f31d5be5d89dd66303b0b4
  • c6def90e73d83bfdfcaff20902a343f7d600f84ecb0a6531aff7b59a06ea8455
  • c9abc638ac5e06271bede0ee3880ef8e034a11bd0cda260ef82d4b6ee978c292


Screenshots of Detection





Indicators of Compromise

Registry Keys
  • Global\I98B68E3C
  • Global\M98B68E3C
  • PEM758
  • PEM60C
IP Addresses contacted by malware. Does not indicate maliciousness
  • 12[.]139[.]45[.]113
  • 216[.]215[.]112[.]198
  • 81[.]215[.]192[.]201
  • 113[.]193[.]217[.]34
  • 96[.]254[.]126[.]140
Domain Names contacted by malware. Does not indicate maliciousness
  • optics-line[.]com
  • ironspot[.]com
Files and or directories created
  • N/A
File Hashes
  • 0a212916b4767564de4a7b5ae348c56b4d9c5a799723e901352280a3e8d64761
  • 0b62c13a5558d201266446b870d97eb458a82eab17d69a3d566a6e5abb158c6a
  • 171e0e8440bb8152cef9ae20dec4a170f93b1312aadf782490cc36adf5c301a4
  • 17b6cacdac7e3dc56d0b60ea7367e5073048e30aff6742e65b0a6f2b52b6255a
  • 1b90e481327517deced0d43590dfd5715ac0d1645f78f65239aa091f653f4c07
  • 2456f8835a6452a6bc07db97990ac81977f1102f41b53ffc68ed935022caee67
  • 2581d63d7d772a3b1ac3b5ae095b03a9a76e771b3d153ac3e95ead93759880de
  • 3c985296fc326089a695b2ffb78ab22b5bf6b0c28b62c9f8532281487479c99c
  • 400d3ec69470e65f173f5ced9fd5bbedfa0458332639d5f48d4d46ad93f19c8a
  • 50c4e66b9f3cbbab3298dc9113b16e485c17feecf296cab4829607942e6b63d2
  • 5e3034a30bef39ff753853f3712bedc99baf5c0e3e84b8de6665e21716e9bf87
  • 63ed9611ef53d62886a487b66638d5b4e022fb791182130d7fcef35a07f79080
  • 6886615f85136e0c0624642251d7b5396c57f7ba5cdce955d2dd0b1f0be7e6f5
  • 6a5ce4ce91c196918807df2bcfefe256d76970e5b8e87b40df1757639943090e
  • 6af525481cb0998d33e3a3c4954da1545f0f6dcb25b899b450d98a4bc3b17c13
  • 7603db9e307d728676caadf8d1e42733071087e6dc72a7a3ec747372fa0c965e
  • 8319cf7cd706879ced641e96ce84ae78286c5eb3a8de911aaa449a922e2af6d4
  • 8cf4ea0f49b0d6a0df0bcb066bea9bf27ee10ac34dd3e240c7cb19582b9041c7
  • 97c4f7a023bf61ca96d3de53931c0fad28ca2197740999e930c8d702a346ffb7
  • 9b58e48bc55057f200d72f6f6646097a4e1285bdea85073c3e0313bd953ee13d
  • 9c8cd646405cc6c78665e8702051107b0531f7918829985335e6f5348c20a873
  • ae445853c56dddcbdf899ab132adb7cd9cfe9eb7048ee643838bb85b7422ac37
  • afddef6744bf508b82295fa1478a03e8016d10c6647925c46a8f0f8ea6bb3a3b
  • b11cc1ae5ed0b068cc101b046a9c2c8a270d751273cf320934b790fe5afb91a3
  • c77fcc0be04543148bbfab87443d2d81a712ba16c24f22963a0670275eab6bb4


Screenshots of Detection





Indicators of Compromise

Registry Keys
  • <HKCU>\SOFTWARE\07771b47
  • C77D0F25
  • 244F2418
IP Addresses contacted by malware. Does not indicate maliciousness
  • 77[.]182[.]47[.]152
  • 77[.]214[.]6[.]192
  • 77[.]198[.]181[.]15
  • 83[.]226[.]115[.]86
  • 77[.]253[.]52[.]129
  • 8[.]123[.]232[.]109
  • 94[.]227[.]178[.]89
  • 8[.]110[.]105[.]136
Domain Names contacted by malware. Does not indicate maliciousness
  • N/A
Files and or directories created
  • N/A
File Hashes
  • 01ce9f47d246b23480249c21385f28af4f8f6c6f72de0e16f0d5995add2cc4f4
  • 0b1e8ab791aa74ec379a8699c6e50fcda918c02b08aa4460bea8a842931cfb1b
  • 0defb11ec4549eb802fb841cbb58ec72f8bde65bbed48245e0d83c6c942d941d
  • 2273e345b799cc3ed8954fd82b62ad47f16615cb59531355039349d7ee84de23
  • 26f4a9f28493a8250d38061536289c0249bb88b8e12cd304a70ae06475b4072e
  • 2e2aa0b99d225a1583cb40ca233054fef69fe724190cfff0b7ffcd6c805223fd
  • 303a92f502157d4a99c21c2ec6cd05cfa2400497df59a2e9ce322333ab6f78a9
  • 404f7030cb01a7cdbae2ab38adafd587aa5da0cfc5bb55b92e7cf7b095ac543c
  • 47326515c02c1fb96899aebf38fd18919682d79a1445ffa343dfa26e70261231
  • 4c509d782de2ef525b83dbd61f70a59a2c64b1bbc8d02f063c0e081a2bc6b214
  • 53b5bc66cc62f04439d75203bd7e0ff040e055c90598741f9dc26c59ce41dd64
  • 5746ac7b26eab61a51ca790eecc9bfdf120fc711f4173c54c99ea653d154bd4b
  • 5a36ad9f59dd0c8906cf6dd9c395785ba449c9dddc3843cc2d9a9aecd5f78c47
  • 65360c29dd0b0cddcbc77cce83af3761439423c72276dd425755e6dbd3bfc171
  • 6653fe7c4e305c524ca7d59ff8286bfe944af1e4672e11f8a08a7cea0a2dd332
  • 6a8a02f29f22cbdcf42ca25ee3d26e4220c70cb133595bc9b3354742bb4a3a2e
  • 743e3645040914b245661a2e145fb3237237cdb30a82ce6ee59461cd83505841
  • 7ca20063faa25398f5e4ddc7d08e5bd39e71d816caeec5214bcb14c261d5ed25
  • 83e460c7faf4d06a0b255a8ad4175577e9b8cdd8bb88645dff1a8841fc4c72ae
  • 8b9e1ef2b8e37a459b1ead71b6b5c684aa5589b3f6a3fc7aacba4b7c0c3085d4
  • 93fd66843eeefba26d494abf82bd69f972913c59e109a97a8871f1150e75ae01
  • 95c587cce682887a0d9d6297e966a9fd82590cf557aac4767eff29ceafa373e2
  • 99f203e4a8ee38b92ca80807b5350974d809505539284fa53d64b83aee28a749
  • a48b79aa1d76c9c8480466757d3d198bfefa19434fe4697129d73bce75a412b0
  • a593ae31f46ba0871580a5d7af3a8abd29fccd164c92dafc6c53f5b69487f717


Screenshots of Detection




Indicators of Compromise

Registry Keys
  • N/A
IP Addresses contacted by malware. Does not indicate maliciousness
  • 176[.]99[.]4[.]7
Domain Names contacted by malware. Does not indicate maliciousness
  • N/A
Files and or directories created
  • %AppData%\Gybyoq\uzbu.ecu
  • %AppData%\Iftovi\ihuk.exe
  • %LocalAppData%\Temp\tmpbed48548.bat
File Hashes
  • 075954d09355c42653ebb8340916245a18e28b8ad5d7c701f2f3208f639922a9
  • 168c7ecd964fcae27d56aeb73ebb5917b2a7f025d708019b870f184e92cf42ab
  • 22bdc85124aa553038e1d5b27411c67b931406597cebdc3ab7eb149077695599
  • 259f3336bd8bb16138f45cf341f7290e7edfbee2872a9927184d02643ac86b85
  • 31903b752e05db104908f6e2853597d5990f0fb5378573f98870c57509765b28
  • 480e51e1bef08a8870a7d852abab4ac58179d2fa8031a9a080ce8a5a04a3f073
  • 508517c5a9cbab74b1458ae66f1b744b74fd1833594eb319592416d7825f5d83
  • 5a8b1aecc07c0c707aabfe22e52a7f70cc65aeac7127f7fd87ddf74a172212dd
  • 5b9b975f6f67ed9bf8f45db61117330b31770dc26aecd0262253531106bc74ad
  • 5e0535beb2b18aa4a2a5db338485f6e87fba66cd79fb0afb0c1cc18a3d526b22
  • 62bbd7305b5ccb36a11f1f8d81065daa537e1716fb1983d8b411993d365b2fda
  • 829cc5bc44063c564e0cbfda5d7c4538df9c6eb54f37eb09cf14757dda2f6ad5
  • 897527a34498f81ffac99f626abcc0045cc5953173c84f90766280d38edc4f73
  • 90e57a0f986925b7bf5a9114ff99d0c764c82c2348ae9694cb3b49a10de49ee8
  • 911529ae29929ba58e3e2f7c2b1db4c8697df181bc1122ed2a96268429eae8c6
  • a3ea8684813d8849686a07809e576ea5276fd63de74fe65406871f7b3b3f185d
  • a52de51d2c4ca3bcb65d3c35b0a02c2b83142d784e420cd06c79d500d24587d3
  • ab3e38a476d1d7e136c670d16afeff8ac0a3f82578d0398ba1ec91792c447411
  • b398d2d8c26361f98d8341bb38e42f9553b107756c0aeb5985688de7af309de6
  • c25837b0eecbcac9726e6f6b41502b65796f5ddd20a42aa0311f18ed85302809
  • db58802e343b45a0d173a3bfab5fae9fe1c6188a6a175042a496f2e7ae1b906e
  • ecb59e655db783f2d4515b90f1045b154827820de20b09ebebe382895726bbcb
  • fa1962bf247694be787999b8b94dba8a09728cb258776b067a01128d3e073d01
  • fa9c078a6fbc67f8545381c4dbef455ce3e4e69c518ffdb6080103b98742b00b
  • fab9b2ba302d819180f19df41bf91abc7370b22fa0a08d35bc6a55dcb9751471


Screenshots of Detection



Support FBI whistleblower Terry Albury, who is set to be sentenced next week


Terry Albury

FBI whistleblower Terry Albury, the second person prosecuted by the Trump administration for leaking information to the press, will be be sentenced next week in federal court. The documents he is assumed to have shared detail the FBI’s recruitment tactics and how the agency monitors journalists. For his act of courage, he could face years in prison.

Albury pleaded guilty to two counts of violating the Espionage Act in March—each punishable by up to ten years in prison. Passed in 1917, the archaic law was originally intended for use against foreign spies, but since its inception, it has been weaponized against sources of journalists and whistleblowers. (Read more about the history of the Espionage Act here.)

Albury is no spy. His attorneys have described him as being driven to action by a “conscientious commitment to long-term national security and addressing the well-documented systemic biases within the FBI.” Albury has stated he witnessed discrimination both as by working as the only black field agent in the agency’s Minneapolis office, and by observing profiling of minority communities in Minnesota.

Although the complaint against Albury did not name a specific news organization, he is assumed to be the source behind The Intercept’s important “FBI Files” investigative series that  detailed controversial FBI tactics for investigating minorities and for monitoring journalists through National Security Letters (NSLs).

By using NSLs, the FBI can obtain journalists’ phone records with no court oversight whatsoever and can circumvent the Justice Department’s normally strict guidelines for spying on journalists. The fact that we know this is (presumably) thanks to Albury.

The charges against Albury came as the Justice Department ramped up its leak investigations by 800% since the previous administration. Albury’s case is the latest in a travesty of leak prosecutions under the Espionage Act, a practice normalized by the Obama administration and expanded on by Trump.

Albury will be sentenced on October 18 in St. Paul, Minnesota. His attorneys argue that guidelines suggest a sentence of approximately three years, but that given his moral character, role as a father of two young children, and the fact that he no longer works for the FBI, a sentence of probation would be most appropriate.

In the sentencing motion, Albury’s defense draw attention to his workplace environment, and how the racism he experienced within the FBI and the racial profiling witnessed the agency propagate in Minnesota sickened and isolated him.

“In 2016, Terry Albury, a highly-regarded and decorated FBI agent in the Minneapolis office (and who had previously served the FBI in Iraq), and the only black field agent in his region at that time, disclosed classified materials to a reporter relating to FBI surveillance, profiling, and informant-recruitment practices in national security cases,” the motion reads. “He did so as an act of conscience, of patriotism and in the public interest, and for no personal gain whatsoever.”

Trevor Timm, executive director of Freedom of the Press Foundation, noted in April that former FBI officials like James Comey and and Andrew McCabe have received extensive media coverage and public and financial support—and don’t face prosecution. But Albury, who apparently released information with huge implications for racial inequity and press freedom, has received very little such support.

Albury's lawyers have launched a GoFundMe page to help with his legal expenses, which you can contribute to here.

The justice system is deeply broken when a courageous whistleblower like Albury should face any prison time at all for speaking out about racial profiling and discrimination within his workplace and making details of monitoring of the press public.

Facebook’s recent hack exposed private information of 29 million users

Late last month, Facebook announced a data breach that affected up to 50 million of its users. The issue involved access tokens -- digital keys that let people remain logged into Facebook -- and a vulnerability allowed attackers to steal those tokens and hijack other users' Facebook accounts. The company has now released an update on that report and it now says fewer people were affected that it originally thought. "Of the 50 million people whose access tokens we believed were affected, about 30 million actually had their tokens stolen," it said.

Source: Facebook

McAfee Database Security in Rapid Deployment Mode

Location independent – speed is everything

Deploying any software into the enterprise has always been a race against time. Every time someone has to manually install software, valuable time for business critical tasks is lost. Ever since the cloud became more than just something for start-up, fast paced companies, the focus of a speedy deployment has increased.

To deploy endpoint related software quickly and seamlessly you may have to use Windows Server Update Services (WSUS) or something similar.

Then, there is software that requires more configuration which generally is a manual process to setup all the required additional services and dependencies; or, in many cases, these are baked into virtual machines (VM) for easy deployment.

Plus, VMs, as practical as they might be, have their own challenges. Often, the overhead created by deploying multiple VMs is considerable, creating a new set of VMs even from templates is generally not what would be considered fast and is impractical for environments requiring rapid deploy and destroy cycles.

The cloud has proven what rapid deployment should look like. New resources are created within a few minutes and are always only a few clicks away. Scalable application services, VM’s, backend databases, everything is easy to roll out and get into production.

Introducing Containers

Container deployments have been around for a number of years, but they have been increasing in popularity over recent years especially in the cloud. It’s easy to see why. Containers are ultra-portable, ultra-lightweight and ultra-fast to deploy.

This lends itself to environments where rapid deployment is a must have. Most cloud platform providers have introduced support for their own container environments. Simple, fast push button deployments in both, the cloud and on premise are becoming ever more popular.

With this in mind McAfee Database Security has recently introduced its offering in a containerized version, both as a Docker image as well as through the Microsoft Azure Marketplace. Not only is this the first security software as a container on Azure’s Marketplace it also underlines the clear direction McAfee Database Security has, providing one set of controls no matter of the location for the monitoring of Databases. This allows for fast and easy deployment of the Database Security solution without the need to go through lengthy install processes.

Take a look at what I had to say at this year’s Microsoft’s Ignite Conference on our recent McAfee Database Security container release:

More information on McAfee Database Security in the Azure Marketplace can be found here, and don’t forget to take a look at the product page.

The post McAfee Database Security in Rapid Deployment Mode appeared first on McAfee Blogs.

The Language and Nature of Fileless Attacks Over Time

The language of cybersecurity evolves in step with changes in attack and defense tactics. You can get a sense for such dynamics by examining the term fileless. It fascinates me not only because of its relevance to malware—which is one of my passions—but also because of its knack for agitating many security practitioners.

I traced the origins of “fileless” to 2001, when Eugene Kaspersky (of Kaskersky Labs) used it in reference to Code Red worm’s ability to exist solely in memory. Two years later, Peter Szor defined this term in a patent for Symantec, explaining that such malware doesn’t reside in a file, but instead “appends itself to an active process in memory.”

Eugene was prophetic in predicting that fileless malware “will become one of the most widespread forms of malicious programs” due to antivirus’ ineffectiveness against such threats. Today, when I look at the ways in which malware bypasses detection, the evasion techniques often fall under the fileless umbrella, though the term expanded beyond its original meaning.

Fileless was synonymous with in-memory until around 2014.

The adversary’s challenge with purely in-memory malware is that disappears once the system restarts. In 2014, Kevin Gossett’s Symantec article explained how Powerliks malware overcame this limitation by using legitimate Windows programs rundll32.exe and powershell.exe to maintain persistence, extracting and executing malicious scripts from the registry. Kevin described this threat as “fileless,” because it avoided placing code directly on the file system. Paul Rascagnères at G Data further explained that Poweliks infected systems by using a boobietrapped Microsoft Word document.

The Powerliks discussion, and similar malware that appeared afterwards, set the tone for the way fileless attacks are described today. Yes, fileless attacks strive to maintain clearly malicious code solely or mostly in memory. Also, they tend to involve malicious documents and scripts. They often misuse utilities built into the operating system and abuse various capabilities of Windows, such as the registry, to maintain persistence.

However, the growing ambiguity behind the modern use of the term fileless is making it increasingly difficult to understand what specific methods fileless malware uses for evasion. It’s time to disambiguate this word to hold fruitful conversations about our ability to defend against its underlying tactics.

Here’s my perspective on the methods that comprise modern fileless attacks:

  • Malicious Documents: They can act as flexible containers for other files. Documents can also carry exploits that execute malicious code. They can execute malicious logic that begins the infection and initiates the next link in the infection chain.
  • Malicious Scripts: They can interact with the OS without the restrictions that some applications, such as web browsers, might impose. Scripts are harder for anti-malware tools to detect and control than compiled executables. In addition, they offer a opportunity to split malicious logic across several processes.
  • Living Off the Land: Microsoft Windows includes numerous utilities that attackers can use to execute malicious code with the help of a trusted process. These tools allow adversaries to “trampoline” from one stage of the attack to another without relying on compiled malicious executables.
  • Malicious Code in Memory: Memory injection abuses features of Microsoft Windows to interact with the OS even without exploiting vulnerabilities. Attackers can wrap their malware into scripts, documents or other executables, extracting payload into memory during runtime.

While some attacks and malware families are fileless in all aspects of their operation, most modern malware that evades detection includes at least some fileless capabilities. Such techniques allow adversaries to operate in the periphery of anti-malware software. The success of such attack methods is the reason for the continued use of term fileless in discussions among cybersecurity professionals.

Language evolves as people adjust the way they use words and the meaning they assign to them. This certainly happened to fileless, as the industry looked for ways to discuss evasive threats that avoided the file system and misused OS features. For a deeper dive into this topic, read the following three articles upon which I based this overview:

ICANN’s internet DNS security upgrade apparently goes off without a glitch

So far, so good. That’s the report from Internet Corporation for Assigned Names and Numbers (ICANN) as it rolled out the first-ever changing of the cryptographic key that helps protect the internet’s address book – the Domain Name System (DNS) on Oct. 11.

The change is central to ICANN’s project to upgrade the top pair of cryptographic keys used in the Domain Name System Security Extensions (DNSSEC) protocol — commonly known as the root zone key signing key (KSK) — which secures the internet's foundational servers. This so-called root KSK rollover from the 2010 KSK to the 2017 KSK was supposed to take place almost a year ago but was delayed until Oct. 11 of this year because of concerns it might disrupt internet connectivity to significant numbers of web users.

To read this article in full, please click here

Happy National Savings Day!

Today is National Savings Day. How are you celebrating?

At Verisign, we did a quick search on NameStudioTM, our easy-to-use, domain name suggestion tool to see what interesting .com and .net domain names were available to register today … and here are some of our favorites!







What’s yours?

Tell us what great .com and .net domain names you’ve found on NameStudio here.

And check back soon to see what day we’re celebrating next. Better yet, subscribe to the Verisign blog to have the posts delivered directly to your inbox.

Happy National Savings Day!

*Available as of October 12, 2018

The user is solely responsible for ensuring that the registration of any domain name listed herein or based on NameStudio domain search data does not violate any third-party trademarks or other intellectual property.

The post Happy National Savings Day! appeared first on Verisign Blog.

Playbook Fridays: Google Alerts RSS Reader

Read a Google Alerts RSS feed and create indicators from the links

ThreatConnect developed the Playbooks capability to help analysts automate time consuming and repetitive tasks so they can focus on what is most important. And in many cases, to ensure the analysis process can occur consistently and in real time, without human intervention.

Once in a while, there is a Google search that turns up a lot of malicious or compromised domains. When this happens, it is helpful to use Google Alerts to create a RSS feed of websites matching the search. This Playbook will then read from the RSS feed on a regular interval and create all of the urls as indicators in ThreatConnect. This is extremely useful for automating the threat hunting process especially when there is an outbreak of compromised hosts that can be easily discovered using a Google search.

ThreatConnect developed this Playbook to read a Google Alerts RSS feed and create indicators from the links.


Getting Started

There are two main parts to this system: a Google alert RSS feed and this Playbook.

There are details and instructions for setting up a RSS feed for a Google alert here: https://thenextweb.com/google/2013/09/11/google-alerts-regains-rss-delivery-option-it-lost-after-google-readers-demise/.

Once you have a Google alert RSS feed setup, you can install and use the Playbook. To do this, go to https://github.com/ThreatConnect-Inc/threatconnect-playbooks/tree/master/playbooks/google-alerts-rss-reader and download the "Google Alert Feed Reader.pbx" file. Now, import it into ThreatConnect. Go to the "Playbooks" tab in ThreatConnect and click "New" > "Import" (on ThreatConnect versions before 5.7, you can just click the "Import" button). Then import the Google Alert Feed Reader.pbx file. Next, set up the Playbook.

To do this:

  1. Double click on the "Run on Interval" app and specify how often and when you would like the app to run.
  2. Double click the "Set Variables" app and provide the URL to a Google Alerts RSS feed. Also, set the confidence and threat ratings you would like to apply to the created indicators.
  3. Find all of the apps which have errors and fill in the missing fields (which include parameters like the ThreatConnect owner and slack API token).
  4. Turn it on and run the Playbook!





The post Playbook Fridays: Google Alerts RSS Reader appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

Thor Enterprise Is Now Best Anti-Malware Solution of the Year

On Thursday, October 11 our hard work and sustained efforts along the years were rewarded on the stage of Computing Security Awards 2018.

We are thrilled to announce that we won the Anti-Malware Solution of the Year for Thor Enterprise, our security product uniquely focused on threat prevention, not just mitigation of cyber attacks.

Organized by Computing Security, one of the most influential and widely read cybersecurity publications, Computing Security Awards 2018 saw 12 products nominated for Anti-Malware Solution of the Year. Out of them, Thor Enterprise rose to the number 1 spot and we are extremely thankful for the recognition awarded to us.

The unique, proactive and reactive approach provided by Thor Enterprise is at the forefront of innovation, offering a modular solution that can fit into any environment, is compatible with existing solutions and provides unparalleled compliance with regulatory bodies worldwide.

The embedded VectorN DetectionTM is a unique threat communication filtering algorithm. It uses behavioral analysis of incoming and outgoing traffic to prevent attacks that cannot be detected by signature-based, reactive solutions like Antivirus.

Through the proprietary and complementary DarkLayer GUARDTM, organizations protected by Thor can map out critical endpoints in their environment. This way, they obtain valuable IOAs and IOCs necessary for true endpoint detection and response (EDR).

The acclaimed X-Ploit Resilience module in Thor Enterprise allows organizations to automatically patch security-critical 3rd-party software across the board, with no location or scheduling restraints, eliminating vulnerabilities and extraneous costs all in one go.

To provide our customers with true next-gen, multi-layered security, Thor Enterprise also includes a market-leading Antivirus module for impeccable detection and threat mitigation.

We are extremely happy to have received this award for Anti-Malware Solution of the Year. Thor Enterprise represents our sustained efforts into providing exceptional security for our business partners in more than 5000 organizations across the globe and for the hundreds of thousands of consumers who rely on us to keep their digital life safe.

We’d like to thank you for your support. We also promise you, once again, that our quest for impeccable, proactive security continues so that you and your projects are safe from cybercriminal interference.

The post Thor Enterprise Is Now Best Anti-Malware Solution of the Year appeared first on Heimdal Security Blog.

Most SMBs Fold after Cyber Attacks: Here’s How to Protect Yours

Many small-to-medium businesses (SMBs) think they’re flying under the radar of cyber-attackers. But in reality, perpetrators specifically target smaller, more vulnerable businesses because of their lack of security expertise and fragile infrastructure, and because they often provide easy entryways to larger companies with whom the SMBs work. Even more alarming, more than 60 percent of SMBs go out of business within six months of devastating attacks, like ransomware and distributed denial of service (DDOS).

In this digital era, where cyber-attacks happen at all times around the world,  SMBs are often the hardest hit, although their breaches may not make headline news. According to a report by Verizon, 61 percent of data breach victims were small businesses. And as Hiscox’s Cyber Preparedness Report 2017 notes, small businesses lose an average of $41,000 per cybersecurity incident.  

The challenge is that SMBs typically have a shoe string IT & security budget and very limited expertise with cutting-edge tools. For instance, a local mom-and-pop store typically has a firewall and anti-virus for their security posture. So DDOS attacks, point-of-sale malware and phishing scams can very easily lead to a huge payout for attackers. Moreover, it is not always easy for business owners to understand what and how to protect their assets from constantly evolving cyber threats.

How MSSPs can help SMBs affordably protect themselves

Small businesses today tend to focus on doing the basics to protect endpoints and servers, which includes staying current on anti-virus updates and security patches for systems and applications. In these organizations, there may be just one person working part-time handling IT. Security is secondary and perhaps an afterthought.

Security breaches can be devastating to a small business that has significant resource constraints. The goal, therefore, is to deliver more data protection at less cost, based on thoughtful risk assessments and business-specific needs. A smart, affordable way for SMBs to protect themselves is by aligning with Managed Security Service Providers (MSSPs), who offer key services such as:

  • Outsourced, advanced-level 24x7 monitoring of security events and management. This is a cost-effective alternative to having dedicated in-house staff managing security events.
  • Deep threat intelligence covering a wide security landscape, such as device management, breach monitoring, data loss prevention, insider threat detection, phishing attacks, web exploits, and more.
  • Incident response to contain and eliminate cyber threats in near real-time and keep your business running.
  • Flexibility of deployment. The MSSP’s services should be available over the internet, via on-premise systems that are managed remotely, or through a hybrid model. SMBs may choose to implement some security capabilities in-house alongside other services from their trusted MSSP.
  • Consulting on industry specific requirements and know-howpertaining to your business. This helps the MSSP   implement  best-practice processes and the right technologies for you.

MSSPs are an increasingly popular choice for SMBs who need a simple, cost-effective solution for cyber threat protection  that leverages the latest innovations and provides 24x7 access to security experts. According to Market Research Engine, global managed security services market revenues could surpass $45 billion by 2022, expanding at a compound annual growth rate (CAGR) of 14.5 percent between 2016 and 2022.

MSSPsare a great resource for either supplementing your existing security team or starting your security practice. However, not all managed security services solutions are created equal. Each provider has different strengths and levels of support for incident management and response, and engagement with your business.

How to choose the best MSSP for your business

Many SMBs have a tendency to pick a security bundle from the managed service provider (MSP) who manages their systems, backups, software upgrades, and routine operations. However, this may not suffice. Not all MSPs have the right cybersecurity service offerings and businesses can’t afford to gamble on using providers that may end up delivering inadequate coverage and cause them to incur excess costs.

Five criteria to look for when choosing an MSSP:

  1. Employs state of the art tools, technologies, well-documented processes and workflows, and clearly articulates the level of interaction they’ll have with your business.
  2. Provides complete visibility of your sensitive data and transparency into the data movements within their environment.
  3. Understands specific issues and requirements pertaining to your industry. Different industries, such as finance, healthcare, and retail, have their own security concerns and benefit from an MSSP that has extensive experience in their area.
  4. Demonstrates compliance with your business’ and partners’ requirements.
  5. Helps you stay ahead of advanced threats by bringing collective knowledge from other customers and sources, such as threat intelligence, government alerts, etc., to educate your team on the latest security issues. This is critical as many data breaches result from employees opening phishing emails, and lost or stolen credentials.

Empirical data shows SMBs have high security-related risks that can be extremely detrimental, compared to larger organizations. Given resource constraints and skills limitations, it is best to align yourselves with MSSPs that can provide superior 24x7 protection and support at affordable prices, freeing you to safely focus on your core competency.

About the author: Arun Gandhi has more than 17 years of experience with startups and global brands in the service provider and enterprise segments. He is currently Director of Product Management and Marketing at Seceon, responsible for driving strategic go-to-market initiatives, positioning, customer use cases, and executive engagements with customers & partners.

Copyright 2010 Respective Author at Infosec Island

Introduction to Verifiable Delay Functions (VDFs)

Finding randomness on the blockchain is hard. A classic mistake developers make when trying to acquire a random value on-chain is to use quantities like future block hashes, block difficulty, or timestamps. The problem with these schemes is that they are vulnerable to manipulation by miners. For example, suppose we are trying to run an on-chain lottery where users guess whether the hash of the next block will be even or odd. A miner then could bet that the outcome is even, and if the next block they mine is odd, discard it. Here, tossing out the odd block slightly increases the miner’s probability of winning the lottery. There are many real-world examples of “randomness” being generated via block variables, but they all suffer from the unavoidable problem that it is computationally easy for observers to determine how choices they make will affect the randomness generated on-chain.

Another related problem is electing leaders and validators in proof of stake protocols. In this case it turns out that being able to influence or predict randomness allows a miner to affect when they will be chosen to mine a block. There are a wide variety of techniques for overcoming this issue, such as Ouroboros’s verifiable secret-sharing scheme. However, they all suffer from the same pitfall: a non-colluding honest majority must be present.

In both of the above scenarios it is easy for attackers to see how different inputs affect the result of a pseudorandom number generator. This led Boneh, et al. to define verifiable delay functions (VDF’s). VDF’s are functions that require a moderate amount of sequential computation to evaluate, but once a solution is found, it is easy for anyone to verify that it is correct. Think of VDF’s as a time delay imposed on the output of some pseudorandom generator. This delay prevents malicious actors from influencing the output of the pseudorandom generator, since all inputs will be finalized before anyone can finish computing the VDF.

When used for leader selection, VDF’s offer a substantial improvement over verifiable random functions. Instead of requiring a non-colluding honest majority, VDF-based leader selection only requires the presence of any honest participant. This added robustness is due to the fact that no amount of parallelism will speed up the VDF, and any non-malicious actor can easily verify anyone else’s claimed VDF output is accurate.

VDF Definitions

Given a delay time t, a verifiable delay function f must be both

  1. Sequential: anyone can compute f(x) in t sequential steps, but no adversary with a large number of processors can distinguish the output of f(x) from random in significantly fewer steps
  2. Efficiently verifiable: Given the output y, any observer can verify that y = f(x) in a short amount of time (specifically log(t)).

In other words, a VDF is a function which takes exponentially more time to compute (even on a highly parallel processor) than it does to verify on a single processor. Also, the probability of a verifier accepting a false VDF output must be extremely small (chosen by a security parameter λ during initialization). The condition that no one can distinguish the output of f(x) from random until the final result is reached is essential. Suppose we are running a lottery where users submit 16-bit integers and the winning number is determined by giving a seed to a VDF that takes 20 min to compute. If an adversary can learn 4 bits of the VDF output after only 1 min of VDF computation, then they might be able to alter their submission and boost their chance of success by a factor of 16!

Before jumping into VDF constructions, let’s examine why an “obvious” but incorrect approach to this problem fails. One such approach would be repeated hashing. If the computation of some hash function h takes t steps to compute, then using f = h(h(...h(x))) as a VDF would certainly satisfy the sequential requirement above. Indeed, it would be impossible to speed this computation up with parallelism since each application of the hash depends entirely on the output of the previous one. However, this does not satisfy the efficiently verifiable requirement of a VDF. Anyone trying to verify that f(x) = y would have to recompute the entire hash chain. We need the evaluation of our VDF to take exponentially more time to compute than to verify.

VDF Candidates

There are currently three candidate constructions that satisfy the VDF requirements. Each one has its own potential downsides. The first was outlined in the original VDF paper by Boneh, et al. and uses injective rational maps. However, evaluating this VDF requires a somewhat large amount of parallel processing, leading the authors to refer to it as a “weak VDF.” Later, Pietrzak and Wesolowski independently arrived at extremely similar constructions based on repeated squaring in groups of unknown order. At a high level, here’s how the Pietrzak scheme works.

  1. To set up the VDF, choose a time parameter T, a finite abelian group G of unknown order, and a hash function H from bytes to elements of G.
  2. Given an input x, let g = H(x) evaluate the VDF by computing y = g2T

The repeated squaring computation is not parallelizable and reveals nothing about the end result until the last squaring. These properties are both due to the fact that we do not know the order of G. That knowledge would allow attackers to use group theory based attacks to speed up the computation.

Now, suppose someone asserts that the output of the VDF is some number z (which may or may not be equal to y). This is equivalent to showing that z = v2(T/2) and v = g2(T/2). Since both of the previous equations have the same exponent, they can be verified simultaneously by checking a random linear combination, e.g., vr z = (gr v)2(T/2), for a random r in {1, … , 2λ}(where λ is the security parameter). More formally, the prover and verifier perform the following interactive proof scheme:

  1. The prover computes v = g2(T/2) and sends v to the verifier
  2. The verifier sends a random r in {1, … , 2l} to the prover
  3. Both the prover and verifier compute g1 = gr v and z1 = vr z
  4. The prover and verifier recursively prove that z1 = g12(T/2)

The above scheme can be made non-interactive using a technique called the Fiat-Shamir heuristic. Here, the prover generates a challenge r at each level of the recursion by hashing (G,g,z,T,v) and appending v to the proof. In this scenario the proof contains log2 T elements and requires approximately (1 + 2/√T) T.

Security Analysis of Pietrzak Scheme

The security of Pietrzak’s scheme relies on the the security of the low order assumption: it is computationally infeasible for an adversary to find an element of low order in the group being used by the VDF. To see why finding an element of low order breaks the scheme, first assume that a malicious prover Eve found some element m of small order d. Then Eve sends zm to the verifier (where z is the valid output). The invalid output will be accepted with probability 1/d since

  1. When computing the second step of the recursion, we will have the base element g1 = gr v, where v = g2T/2 m, and need to show that g1T/2 = vr(zm)
  2. The m term on the left hand side is mT/2
  3. The m term on the right hand side is mr+1
  4. Since m has order d, these two will be equal when r+1 = T/2 mod d, which happens with probability 1/d

To see a full proof of why the low order assumption is both necessary and sufficient to show Pietrzak’s scheme is sound, see Boneh’s survey of recent VDF constructions.

The security analysis assumes that one can easily generate a group of unknown order that satisfies the low order assumption. We will see below that there are not groups currently known to satisfy these constraints that are amenable to a trustless setup, i.e., a setup where there is no party who can subvert the VDF protocol.

For example, let’s try to use everyone’s favorite family of groups: the integers modulo the product of two large primes (RSA groups). These groups have unknown order, since finding the order requires factoring a large integer. However, they do not satisfy the low order assumption. Indeed, the element -1 is always of order 2. This situation can be remedied by taking the quotient of an RSA group G by the subgroup {1,-1}. In fact, if the modulus of G is a product of strong primes (primes such that p-1/ 2 is also prime), then after taking the aforementioned quotient there are no elements of low order other than 1.

This analysis implies that RSA groups are secure for Pietrzak’s VDF, but there’s a problem. To generate an RSA group, someone has to know the factorization of the modulus N. Devising a trustless RSA group selection protocol–-where no one knows the factorization of the modulus N–-is therefore an interesting and important open problem in this area.

Another avenue of work towards instantiating Pietrzak’s scheme involves using the class group of an imaginary quadratic number field. This family of groups does not suffer from the above issue where selection requires a trusted third party. Simply choosing a large negative prime (with several caveats) will generate a group whose order is computationally infeasible to determine even for the person who chose the prime. However, unlike RSA groups, the difficulty of finding low-order elements in class groups of quadratic number fields is not well studied and would require more investigation before any such scheme could be used.

State of VDFs and Open Problems

As mentioned in the previous section, both the Pietrzak and Wesolowski schemes rely on generating a group of unknown order. Doing so without a trusted party is difficult in the case of RSA groups, but class groups seem to be a somewhat promising avenue of work. Furthermore, the Wesolowski scheme assumes the existence of groups that satisfy something called the adaptive root assumption, which is not well studied in the mathematical literature. There are many other open problems in this area, including constructing quantum resistant VDFs, and the potential for ASICs to ruin the security guarantees of VDF constructions in practice.

As for industry adoption of VDF’s, several companies in the blockchain space are trying to use VDF’s for consensus algorithms. Chia, for example, uses the repeated squaring technique outlined above, and is currently running a competition for the fastest implementation of this scheme. The Ethereum Foundation also appears to be developing a pseudorandom number generator that combines RANDAO with VDF’s. While both are very exciting projects that will be hugely beneficial to the blockchain community, this remains a very young area of research. Take any claim of security with a grain of salt.