digininja
-
Posts
4,005 -
Joined
-
Last visited
-
Days Won
210
Posts posted by digininja
-
-
Search for the dc4420 group, they meet once a month in London.
-
This sounds very much like a homework question so let's start with you, where do you think they can be used?
-
Probably your best option is to use Tails, it will do all the setup for you. Their site also has documentation on getting you started.
Just remember that no solution is perfect so never assume what you are doing is completely private, it all depends on the resources of your adversary.
-
1
-
-
Me thinks you aren't taking this super leet hacking group seriously.
-
We don't allow or condone illegal activities on this site, even if you believe you are doing them for the good of society or have the moral high ground.
What are the plans for this group of yours?
-
Try talking to them, I'm pretty sure they both have people on staff that can help you. It it fairly specialised so maybe not the type of thing that ends up on the web site.
-
Assuming you are based in the US, look at Black Hills Infosec and Inguardians , both have people on staff who have done work in the area.
-
Check for weak local user passwords and weak domain ones that are cached.
Definitely look at the man in the middle for app updates, it can be an easy way to get code running on the box as admin.
-
Does the machine boot from fully off without requiring a password? If so, look for open ports, see what services it is running that are exposed to see if any of those can be exploited.
See what the box calls out to when booted, do any of those include credentials? Can any of those be intercepted? Maybe an app checks for updates that you can intercept and reply with a custom one.
I've not kept up on them, but do the FireWire attacks still work? There was a DMA issue where you could read memory. There was a second interface type that also allowed it, can't remember which it was.
-
That's not a pentest.
First, define your risks, for example, stolen when turned on, turned off, standby, sleep. Then take each of those scenarios and see what state the drive is in and see if you can access it locally or remotely.
If it is on and there is VNC with no password then FDE does nothing, if it is off and the password for the encryption I'd strong then you are likely to be OK. You need to think of all the different things between these two.
-
Define what you mean by pentest it.
-
Very simple, you don't.
It is illegal to attack systems you don't own or have permission to attack and despite this being "your work" address, you would be attacking Google who don't take kindly to that type of thing.
-
1
-
-
Lets look at your assumptions....
If you are worried about a rogue sh or bash process then you have to be assuming that someone has managed to get something onto your machine in the first place, how they did that, I don't know.
You are also then assuming that, once the rogue app is on there, that it is set to run in some way, again, this is based on your assumption that something malicious is running that is creating the sh or bash processes.
So, making those two assumptions, I would install a ruby script rather than something that requires bash or sh to run, I would then have that start using the ruby interpreter which would create a ruby process, not a bash or sh one. That would not get killed by your script as it isn't looking for ruby
And I did test the script, once my script is running, there are no additional bash or sh processes created.
-
No I wouldn't, there are loads of ways to get shell on a machine that don't involve either bash or sh.
The following ruby script will execute the sleep command which will sleep for 60 seconds, run this and see if your killall kills it.
#!/usr/bin/env ruby %x{sleep 60}
Then simply update the script to listen on a network port for commands coming in and then have it execute them instead of the sleep. One shell, no bash or sh.
And, as I said before, if I wanted a bash like shell, I'd just drop tcsh, zsh or csh on there and use one of those which you aren't killing.
-
If that is the crux then I'd just use csh or tcsh if I wanted a shell.
-
I'm curious, why would the NSA target you? Could it have been the Israeli 8200 or British GCHQ? Australian SIGINT?
Be careful sharing too much, it might not be just cyber that they attack you through next time.
And if you are really paranoid, don't post stuff like this from your Comcast IP, it tells them where you are!
-
Your initial idea was about segmentation, you are now talking about controlling admin creds and monitoring logs, I'm missing the bit that is novel.
-
So is your idea the same as wireless client isolation or something different?
And you could argue that locking down a workstation is easier than a server as a server by definition has to have open services while a workstation can have all listening services disabled. The most common way to do lateral migration is through SMB which should never be needed on workstations as they don't need to offer network shares. It is very rarely disabled though.
-
Drop wireshark or tcpdump on both machines and watch for traffic. If you see it going out then the victim is calling home but being ignored or not being seen, if you don't see the call out, the victim is broken, if you don't see the receipt on the attacker machine, the routing is broken, if you see traffic on the attacker then the listener is broken.
-
Generate your exe on the command line and make sure you pass the right parameters.
https://www.veil-framework.com/veil-command-line-usage/
Also make sure your listener is using the correct handler.
As an extra check, fire up Wireshark on both machines to watch for network traffic.
-
Can you ping victim to attacker, that is the important route for a reverse connection.
What command are you using to build the exe?
-
Did you build the executable properly and is it pointing at your correct IP and port? Can the two machines see each other?
-
If you are able to lock the network servers down to a point you are sure they can't be compromised, why not do the same to the clients. That should probably be easier as servers generally have to expose more services than clients to do their job.
Segmentation is the base of a lot of hardening guides, is a good idea and is nothing new. I think the concept you are going for is the same as client isolation on a wireless network where devices are not allowed to talk to each other, only the AP and devices on the other side of it.
If you subnet down to small groups or teams then that helps isolate them in the event of a compromise but as a lot of compromises bounce from workstation to server and the servers would need to have access to other groups, the network could still be traversed it would just be harder. More choke points introduce more chance of detection so that is a positive.
-
Best way to stay secure?
in Security
Posted
Just to be pedantic, a live OS wouldn't stop stuff being installed but would stop persistence over reboots.