|
Not very, assuming you're referring to "tunnelling" via udp/53 for the purpose of exfil/C&C. It's extremely easy to spot and there are far better methods available.
|
#
¿
Nov 25, 2015 22:03
|
|
|
|
| # ¿ Apr 19, 2024 22:52 |
|
|
ming-the-mazdaless posted:A year ago, I did a Proof of Concept for insider threat detection in a hospital group. Have you followed responsible disclosure and who did you disclose to originally? Edit: actually just listen to OSI Bean Dip vvv Pile Of Garbage fucked around with this message at 16:59 on Mar 4, 2016 |
|
#
¿
Mar 4, 2016 15:08
|
|
|
DeaconBlues posted:I wouldn't have a clue what to look for in a bunch of decompiled c, so the basis of my assumption is sociological: Facebook is part of the status quo, and makes a pretty penny from being there. Why would they want to upset that balance by offering 'true' unbreakable end to end private messaging and also open up possibilities where they have to defend themselves against gov/FBI/yadda? In 2014 Facebook setup a hidden service which makes their website accessible via Tor. By doing this FB increased the number of people using their service, especially in countries with restrictive government censorship practices. FB make money through the number of people using their service. This is why they setup that Interner.org outfit. If they think that they can attract more users to their service by implementing end-to-end encryption then they will more than likely do it. The quality of said encryption is moot as anyone who actually wants end-to-end encryption would avoid using a third-party service. Basically I'm not really sure what your point is. Also what Subjunctive said.
|
|
#
¿
Apr 22, 2016 16:06
|
|
|
Cugel the Clever posted:What is the thread's input on consumer-level firewall software solutions? Is firewall software on the whole more credible than anti-virus software? I've seen GlassWire recommended, but could use a second opinion. Your OS already has a perfectly functional firewall (Unless you've turned it off and in that case turn it back on you dummy). That Zemana Anti-Logger software looks like snake-oil and is probably as equally ineffective as any other "internet security" software (And based off a quick Google search, just as vulnerable).
|
|
#
¿
May 19, 2016 00:24
|
|
|
Cugel the Clever posted:Sounds good. Definitely haven't turned off my OS firewall--just curious about additional services that might augment things. Of course, each additional service is potentially an additional attack vector... The effectiveness of additional services entirely depends on where you're using the product. On your home network where your PC is behind NAT and you trust the internal network it's essentially useless.
|
|
#
¿
May 19, 2016 16:32
|
|
|
Wiggly Wayne DDS posted:not apt enough
|
|
#
¿
Jun 8, 2016 02:55
|
|
|
Wait so are they saying that they will no longer use a filter driver for I/O interception?
|
|
#
¿
Jun 30, 2016 17:45
|
|
|
Cugel the Clever posted:An honest, if inflammatory question: Does Classic Shell have legitimate use scenarios beyond autists obstinately refusing to adopt modern UI? No
|
|
#
¿
Aug 3, 2016 17:02
|
|
|
According to the PsExec page on the Windows Sysinternals site "the password and command are encrypted in transit to the remote system." https://technet.microsoft.com/en-us/sysinternals/pxexec. Of course as always it's worth verifying yourself with a packet capture. Usually my objections to PsExec are because it's being used in a manner that isn't appropriate. If you're doing a bit of ad-hoc troubleshooting then PsExec is fine but if you're attempting to implement large-scale automation then you should really be using WinRM (As Mustache Ride already mentioned). I see idiots implementing PsExec wrappers in PowerShell scripts all the time and it's dumb as hell.
|
|
#
¿
Aug 5, 2016 02:18
|
|
|
22 Eargesplitten posted:My senior admin doesn't want to configure WinRM because he thinks it's insecure. Which means I can't just invoke-command, I have to PSExec and use the command that way. I would also have to automate configuring WinRM on every machine in the environment. Your senior admin is a dingus. WinRM can be easily configured via Group Policy and whatnot on all your devices. If you need to store a password securely then you can use ConvertFrom-SecureString and ConvertTo-SecureString. First you encrypt the password and output it to a file (Note that you have to run this command as the user account which will be executing the script as it uses PBKDF2 to derive the encryption key): quote:ConvertFrom-SecureString -SecureString (Read-Host -AsSecureString -Prompt 'Enter String') | Out-File -FilePath "$env:TEMP\encrypted.txt" Then in your script you can retrieve the encrypted password, convert it to a secure string and then create a PSCredential object along with the username: quote:$CredentialObject = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList ('username', (Get-Content "$env:TEMP\encrypted.txt" | ConvertTo-SecureString)) I use this method with scripts for Office 365/Exchange Online automation and it works nicely. Oh and lol, there's a PowerShell thread? I would be all up in that where's it at? Edit: it's probably already clear but the snippets above are examples. Don't just store the file in the temp folder, put it alongside the script and configure NTFS ACLs on it so that only the service account that will be executing the script can read it (Just a little bit of extra protection although not infallible). Pile Of Garbage fucked around with this message at 09:42 on Aug 5, 2016 |
|
#
¿
Aug 5, 2016 09:36
|
|
|
angry armadillo posted:Does anyone here work in Australia particularly in anything Government related? Have a few potential questions Anyone who does probably wouldn't discuss it here. I know people who do though.
|
|
#
¿
Aug 26, 2016 01:41
|
|
|
angry armadillo posted:True. I'm heading out there for some work and wondered if the Government IT security people have as high standards as they do in the UK or will my life be easier over there It really depends what you're doing and which department you're doing it for. Obviously the AFP, ASD, ASIO/ASIS and anything else defence related have extremely strict standards however other outfits like the AGD and DFAT have standards which are equally strict. Others like the ABS (lol) and the ATO aren't as strict overall but some of their functions are held to much higher standards (e.g. ABS and ATO sometimes exchange data on encrypted USB drives which are taken between the offices via armed escort). I guess a good way to tell how strict things will be is whether S/TS clearance is mandatory for the position (Of course this doesn't always hold true). If you're working for state government then it differs wildly but is terrible more often than not (e.g. Parliament of Western Australia, holy hell are they terrible). All of this is really moot as you'll encounter the same issues working for government as you would anywhere else (Management that doesn't care and deliberately obstructs any attempts to increase security, ancient infrastructure supporting ancient software which is almost possible to protect, third-party developers and MSPs which keep doing dumb poo poo, etc.). Have fun and enjoy Australia!
|
|
#
¿
Aug 26, 2016 12:26
|
|
|
The majority of the work with SIEM products is normalising the data coming in so that it can actually be correlated. Any product which makes that simpler would be good, McAfee SIEM is terrible from what I've seen.
|
|
#
¿
Sep 28, 2016 08:26
|
|
|
I've been petitioning HR to change my title to Associate Systems Specialist or rear end.
|
|
#
¿
Nov 5, 2016 05:57
|
|
|
Internet Explorer posted:Sorry, I only store my hashed password database on an encrypted flash drive stuffed in my rectum that requires a specific sequence of hot peppers at random Scoville values to dislodge. KeepAss, literally.
|
|
#
¿
Nov 15, 2016 06:34
|
|
|
Depends on whether the endpoints are locked down via Group Policy to only accept specific devices...
|
|
#
¿
Nov 21, 2016 19:00
|
|
|
psydude posted:Which is basically never. Where I work it certainly is, across the entire fleet, and I'm not even in a particularly high-sec industry (Well...yeah). It's very easy to implement and surprisingly unobtrusive unless you've got some real garbo devices. Of course that won't block things like the Rubber Ducky but if you're worried about that then you've already epoxied the USB ports on all endpoints. In fact if you're worried about about PoisonTap which requires direct access then you'd be jamming two-part in all visible holes... Pile Of Garbage fucked around with this message at 19:32 on Nov 21, 2016 |
|
#
¿
Nov 21, 2016 19:23
|
|
|
First one, then the other.
|
|
#
¿
Nov 21, 2016 19:31
|
|
|
The best password is the default Oracle one which they use on everything from the JRE keystore to StorageTek LTO tape libraries: changeme I've never seen it changed...
|
|
#
¿
Dec 5, 2016 12:04
|
|
|
RFC2324 posted:Doesn't dell use it too? I know it was the default for both Sun and Dell servers at one fortune 500 I have worked at, tho it may have been baked into the dell firmware update they ran before I got my hands on the hardware. Never worked with Dell but maybe the commonality is JRE-based management thingos? Is there a default password constant in JRE which happens to be changeme? pr0zac posted:And this is why you don't work in infosec (I hope). Also 1000x this ^^^
|
|
#
¿
Dec 5, 2016 17:10
|
|
|
Platystemon posted:The FSF is heavily infiltrated by intelligence agencies, who are deliberately sabotaging infosec. 
|
|
#
¿
Dec 22, 2016 13:17
|
|
|
If I was Red Team and wanted to try and elevate privilege the first thing I would look for is a Scheduled Task configured to run a PowerShell script in the context of a privileged service account. Then I would see if I can edit the script referenced by the task. I'd reckon that 9/10 times the NTFS permissions on the .ps1 file would allow an unprivileged user to edit it. Depending on how privileged the service account is you can cause some serious havoc. If you're running PS scripts via Scheduled Tasks either setup signing and/or lock-down NTFS permissions on the script files themselves. Also deploying WMF 5.0 to your fleet is beneficial as you can then enable auditing for PowerShell on endpoints. Not exactly a security feature but does provide a good source for monitoring. Edit: whilst I'm here I want to say that disabling Windows Firewall on servers is the dumbest loving thing ever unless you have reason to do so (Performance usually the thing). Pile Of Garbage fucked around with this message at 16:31 on Feb 2, 2017 |
|
#
¿
Feb 2, 2017 16:24
|
|
|
With Server 2012 R2 and later the default PowerShell execution policy is RemoteSigned which will prevent unsigned scripts from running. Scripts for other Microsoft products such as Exchange are already signed to accommodate this configuration. As far as I can tell no Microsoft products including Windows will attempt to run a ps1 via Scheduled Task. Realistically the only thing which the default execution policy interferes with is flesh and blood admins. Best practice would be to setup a jumphost with a modified execution policy for admins to work from. In addition installing WMF 5.0 and configuring PS auditing would help for oversight.
|
|
#
¿
Feb 2, 2017 17:18
|
|
|
Like most things on Windows the best way to limit exploitation is to enforce RBAC and ensure that privileged accounts cannot be misused. The commands executed by a PS instance are only as powerful as the context in which they are executed.
|
|
#
¿
Feb 2, 2017 17:23
|
|
|
Preventing the malicious usage of PS scripts is the same as preventing malicious usage of any software. As I said, enforce RBAC policy, limit your privileged surface area and ensure that auditing is enabled. A PS script is only as powerful as the context in which it is executed.
|
|
#
¿
Feb 2, 2017 17:41
|
|
|
Let POLP be your guide. If you need a service account to execute a Scheduled Task on a server then just give it the "Log on as a batch job" user right which is the minimum required to execute tasks. Too often have I seen service accounts granted local Administrator privileges on a server simply for the purpose of running a task which does not require any privileged permissions.
|
|
#
¿
Feb 2, 2017 19:02
|
|
|
Martytoof posted:How do you guys deal with "black box" products going into your environments that are really just Linux based appliances? Enforcing hardening standards seems unfeasible since you typically have no visibility into the inner workings of the solution but just trusting a vendor to harden the device seems like a foolish thing to do. I'm fairly sure if I go to a vendor and say "we need this hardened to CIS level 2" they'll just reply "nope" so all of a sudden I have to create exceptions for my own policies and hope to put enough compensating controls around the black box. I'm getting a headache trying to figure out what kinds of questions to even ask short of just asking vendors to describe the security of their appliance to me which will likely result in a boilerplate PDF with buzzwords. Very carefully. But seriously, try and segregate its comms on Layer 2+3 (May not be possible depending on what you got). Throw it in a DMZ of some sorts. Of course if you're dealing with an appliance like Qualys vuln scanner then it needs access to your entire network so you: Volmarias posted:Just assume that it's a ticking time bomb that will never ever receive security updates. and pray.
|
|
#
¿
Mar 5, 2017 15:06
|
|
|
Unless there's some dumb compliance reason it all just comes down to developer inclination/laziness as to whether or not they implement a form control to disable masking on the password text-box.
|
|
#
¿
Mar 8, 2017 08:56
|
|
|
As long as we agree that every single person involved should be fired out of a cannon into the sun.
|
|
#
¿
May 11, 2017 18:48
|
|
|
EVIL Gibson posted:Found some remote xss on a popular web app but also found out it sends the payload but does not execute in their Android/iOS client. Name and shame or keep it on your blog. Or go full disclosure right here so we can all eat bans
|
|
#
¿
Jun 13, 2017 12:34
|
|
|
Hey mate if you want to talk tech then post away or xpost to the yossec thread. Sorry for being a brash poo poo oval office.
|
|
#
¿
Jun 13, 2017 18:36
|
|
|
Lain Iwakura posted:I would wager that they're accounts that have had been deleted and thus are only referenced by their GUID? Correct, it will display "Account Unknown" if it cannot translate the SID into a SAM account name which usually happens if the account is deleted or if the account is a domain account and the server cannot contact a DC. So yeah, doesn't really mean anything.
|
|
#
¿
Jun 26, 2017 07:18
|
|
|
hobbesmaster posted:Don't share your account with your cat. Correct, only good dogs can be trusted with your credentials (All dogs are good dogs).
|
|
#
¿
Sep 13, 2017 17:17
|
|
|
fyuck you rear end in a top hat all dogs good dogs
|
|
#
¿
Sep 13, 2017 18:09
|
|
|
Infosec is minimum 50% theatre.
|
|
#
¿
Oct 13, 2017 12:55
|
|
|
EVIL Gibson posted:Less than the average cost of code name+ logo for your vulnerability Garbage like that shits me to tears. Heartbleed is mostly to blame, albeit inadvertently, for the trend of branding and marketing vulnerability disclosure for fame and/or fortune. IMO if you consider "inventing a snappy name and registering a domain for the vulnerability" a pre-requisite for full disclosure then your vuln is probably trash. Oh and if you setup a "disclosure countdown clock" you can gently caress right the hell off.
|
|
#
¿
Oct 13, 2017 15:02
|
|
|
Talas posted:Someone left a format disk command line in one of our servers, just needed an Enter to wipe out the main disk... the admin is calling everyone with access to accusing us of trying to prank him. If the server in question is a VMware VM and the offending prompt was found on the VM's console then you can check the events for the VM to determine who launched the console. Of course this is assuming everyone has separate accounts to access your VMware environment. If that is not the case then buddy you've got much bigger problems.
|
|
#
¿
Dec 22, 2017 17:27
|
|
|
Read up on RBAC and principle of least privilege, then apply these concepts to your environment.
|
|
#
¿
Dec 22, 2017 17:37
|
|
|
ChubbyThePhat posted:I have a client with an instance of RBAC that has gone completely out of control. The base concepts are all still there but they really went a little too HAM on the whole idea. At the end of the day RBAC is only as good as your policy and your enforcement tool. If your policy is poorly defined then you'll end up with inefficient and/or inappropriate delegations. If your tool is poo poo then your ability to align configuration with policy and do the nuts-and-bolts of RBAC (Approval workflows, privilege-to-role mapping, auditing, etc.) will be hampered. The specific scenario you mentioned can be handled with a tool which supports JIT delegation. Of course, this requires you to have a tool which isn't terrible. Edit: I can't recommend any RBAC tools however I can say that the CA offerings are absolute garbage so steer clear of them.
|
|
#
¿
Dec 22, 2017 18:13
|
|
|
|
| # ¿ Apr 19, 2024 22:52 |
|
|
Orcs and Ostriches posted:That's more of an organisational issue than a technical one, but I like to see groups in the permissions list, not users. 
|
|
#
¿
Dec 23, 2017 07:06
|
|